On Tue, Dec 22, 2009 at 10:35 AM, Michael Wild <them...@gmail.com> wrote:
>
> On 22. Dec, 2009, at 16:22 , David Cole wrote:
> <snip>
> >>
> >> That's exactly my point: if the dependent project is the calling project
> >> (i.e. the one that calls ExternalProject_Add), you have to use
> error-prone
> >> ADD_LIBRARY(<name> <type> IMPORTED) calls with according invocations of
> >> SET_TARGET_PROPERTIES(<name> PROPERTIES IMPORTED_LOCATION <filepath>).
> In
> >> the case of Boost this is probably very difficult to get right, because
> from
> >> what I hear, the library names change almost randomly with operating
> system,
> >> compilation flags and what not. So what ExternalProject.cmake is
> missing, is
> >> a mechanism of "pulling" the targets of the external project into the
> >> calling project.
> >>
> >>
> > So first build boost and everything with a simple "build my
> prerequisites"
> > project that builds/installs all your prereqs in a nice, reasonable
> fashion.
> >
> > Then your project can just find/include/import everything as your
> accustomed
> > to without any fuss.
>
> That is a workable solution for "tech-savvy" users, I'm not so sure the
> average admin will appreciate it (remembering the heated and quite
> ridiculous discussions on KDE not providing a configure script anymore...)
>
> > There will never be an easy way to pull external projects directly into a
> > calling project because the external things are not even guaranteed to be
> on
> > disk yet at configure time of said calling project.
>
>
> Yeah, kind of a chicken-egg problem...
>
Exactly. That's why we didn't try to solve that problem. If you have a
chicken-egg problem to solve, you have to choose starting with a chicken or
an egg, thereby alienating approximately 50% of your audience, even if you
have good reasons for your choice.
So: there is one approach that's sort of a hybrid here, that I'll mention
because it might be useful to consider.
You could have a cmake option in your project that builds your project one
of two ways: "as usual" or as the final link in a chain of
ExternalProject_Add calls. I've done this and I know it works, but it's
proprietary and I cannot point you to the source code. This technique,
however, does make things hard to think about at times...
Something like this in CMakeLists.txt:
==================================================
option(MYPROJ_UBERBUILD "If ON, build all prereqs first, then build me..."
ON)
if(uberbuild)
include(BuildAllViaExternalProject.cmake)
else()
include(BuildJustMe.cmake)
endif()
And as the last thing inside BuildAllViaExternalProject.cmake:
==================================================
ExternalProject_Add(
DOWNLOAD_COMMAND ""
CMAKE_ARGS
-DMYPROJ_UBERBUILD:BOOL=OFF
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
...
)
The net effect is that a project can build itself as an ExternalProject with
the "clever (?)" use of a CMake option....
HTH,
David
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
