[CMake] Fwd: Build only what you need in third party libs

Asmodehn Shade asmodehn at gmail.com
Tue Dec 22 14:20:35 EST 2009


Thanks guys,
I ll have a look at External Project sometimes too, seems it could make my
code a bit simpler.

For what it s worth, in my custom build framework, to make things simple I
assume a few ( very arguable and arbitrary ) things. Among them :
- the source and build folder hierarchy is known and always the same, which
helps me to automatically detect built things in the right place.
- I expect the developer to build his dependencies when needed ( a simple
"build just me" choice ), but I ( try to ) provide dependencies detection...
For automatic building I would use the  "simple shell script" solution, that
will build things in the right order.

This enables me  to generate automatically and consistently the
*Config.cmake and the *Export.cmake files which makes the job so much easier
:-)

In conclusion I d say that when it s possible for you to know how are your
source tree and your build tree organized, it becomes easy to manage
multiple related projects, as you can automate most of the build steps.

--
AlexV

2009/12/22 David Cole <david.cole at kitware.com>

> On Tue, Dec 22, 2009 at 11:29 AM, Brian Davis <bitminer at gmail.com> wrote:
>
>> <snip>
>>
>>>  > 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.
>>>
>> <snip>
>>
>> I like cake.  I like eating it too.  Mmmm cake!
>>
>
> One could argue that CMake itself is simply a horrific misspelling of "Mmmm
> cake"... And that cmake-gui is like cmake with frosting.
>
>
> Cmake may not *know where the third party is when it configures*, but it
>> *knows where it will be*.  The build will/could take care of the rest.
>> Correct?
>>
>
> I think "could" is fairly optimistic actually. It would be possible if you
> had perfect knowledge of the install tree of each and every project you're
> depending on. But some of the details are not known by CMake until after
> that project is built and installed. We allow people to write their own
> arbitrary stuff into their *Config.cmake files... so it ends up being
> arbitrary. And some external projects are actually not even built with
> cmake. (Gasp!)
>
> CMake will never provide the perfect solution to this problem. However, if
> you are willing to do the work necessary, it would certainly be possible for
> your project to pre-define stuff in such a way as to make it "do-able". It
> might not be fun, but it could be possible.
>
> :-)
>
> Good discussion on all this stuff today. This has been a fun day so far.
>
> Thanks to all of you who've participated,
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20091222/02336263/attachment.htm>


More information about the CMake mailing list