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

[David Cole]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20091222/518bc0e3/attachment.htm>