There is more to do here, this is just the first step. I think as a follow up I would like to separate out an enum into a separate header, and consider properly separating the header only part from the core. I pulled apart a header that was trying to be a little too helpful, and then added a few dependencies that are needed. It also highlighted that I should probably pull a lot of the header only code into a header only library that is much easier to express these days. ![]() So I put this together into a new pull request. I found a number of those instances and now the build system is more robust as it will fail much earlier if it attempts to include headers for libraries there is no dependency specified for. Normally you would get an error about missing symbols, but Avogadro has a number of templated or inline classes, especially in core that will just be built straight into the calling code. This obviously broke a few things as it is much more granular and over the years a few things snook in. This allowed me to remove a bunch of include_directories calls, and carry that information with the target only to the things that state that they want that target. target_include_directories($Īdding the above means that within our build system as we build, or as the Avogadro application builds against our build tree, or as someone builds against the installed Avogadro libraries we can just add the target to our target_link_libraries call and avoid changing the global using include_directories. They let us specify our include directories for both the build and install tree, and the expression will be evaluated later when something wants to consume the target we are creating. Now if you want to use target_include_directories and continue supporting that than generator expressions are needed. One of the other things we have always done well in projects I have developed is let you build against a build tree or an install tree. This was a compromise at the time to make things as modern as we could without all the fancy target properties. Instead as each add_subdirectory call was made the include directories were globally added to for each library. Until I made a PR this morning it had not used the new (to Avogadro’s build system) target_include_directories capability. It also takes care of generating an export header, and tweaking include directories. This function will first call add_library from core CMake, then a little regex to turn AUTOMOC on if it is a Qt-based library, before setting the version of the library. ![]() ![]() Like many projects the Avogadro build system adds a project specific add library function, imaginatively named avogadro_add_library shocking as it might be. Today I had a chance to take the first step in addressing some of that by adding target include directories to the Avogadro libraries. When I first designed Avogadro’s build system I made it as modern as I could at the time, and then reluctantly wasn’t as aggressive as I might have liked in pushing the minimum version higher for modern CMake features. I thought that there was a good chance I wouldn’t make it today as I had a few other commitments but here we are. Not that I am counting, but this is day six.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |