celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Fwd: Project structure
Date Thu, 07 Jun 2012 08:41:31 GMT
I accidentally mailed this message to Sascha directly, it was supposed to
go to the list. So here it is!

---------- Forwarded message ----------

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message