I accidentally mailed this message to Sascha directly, it was supposed to
go to the list. So here it is!
---------- Forwarded message ----------
Hi,
Skipping most of the message..
>
> I however cannot see how using custom configure calls by invoking CMake
> via a custom command on the dependent projects would solve the build
> dependencies. You could configure the actual project, but not link it
> unless it only needs header files. If you would have to add "custom build
> steps" for dependent projects too, you are pretty much replicated the
> features of the CMake ExternalProject macro.
>
What I created is indeed basically a simplified ExternalProject. All it
does is running CMake and the selected generator (Make, etc). It doesn't
download anything etc.
Projects list their dependencies, and a macro and the Config files take
care of configuring and building. Using the Config file the project can
include the libraries/headers etc.
To make the configure/build work a few lines of CMake code is needed, while
the ExternalProject can do much more.
This is a first step to a solution where ExternalProject is used.
> I think I got you :-)
>
> Personally, I would start with BUILD_* options, {Project}Config.cmake
> files, and find_package() calls, using a top-level CMakeLists.txt file for
> "gluing" stuff together. The more elaborate "ExternalProject" case could
> then easily be implemented on top later.
>
I prefer the solution in between, already separate projects, but no
ExternalProject. I will also try your solution. Maybe it is a simpler first
step towards a more modular project structure.
My proposed solution has a large impact on the existing structure, maybe a
step in between would be a smart move.
>
> - Sascha
>
>
--
Met vriendelijke groet,
Alexander Broekhuis
--
Met vriendelijke groet,
Alexander Broekhuis
