[CMake] faq update?

[Brandon Van Every]

On 9/13/07, KSpam <keesling_spam at cox.net> wrote:
>
> What is the point of having a Wiki if not to document such things?  Anyone can
> figure out basic CMake usage from CMake docs.  This is beyond the scope of
> CMake docs; therefore, it belongs on the Wiki.

It's not about what belongs in the wiki.  It's about what belongs in
the *FAQ*.  The FAQ is an ambassador for CMake best practices.  FAQs
that sprawl are not very useful.  We've got the entire wiki to put
stuff on, it doesn't have to all go in the FAQ.

"It might be a dealbreaker if we don't have this stuff in the FAQ" is
also the wrong argument.  CMake FAQs cannot solve fundamental problems
of political will.  If a committee is harping on this or that detail
of a build system, without assigning responsibility for a pilot
project, then they aren't serious.  They are looking for reasons to
avoid a decision, rather than getting on with producing results.

I don't have a problem with these hacks / workarounds being in the FAQ
if the limitations upon their use are well explained.  Emphasis on
*well* explained.  New information for a specific corner case should
not muddy the waters for the vast majority of CMake users out there.
What most CMake users need to know is, they were wrong that they
thought they could re-use their differently compiled SHARED and STATIC
objects.  The number of users who have shown up on this list, who
really really did have identical flags and really really can reuse
them, is pretty low.  I'm one of 'em and my solution is better than
most other people's, in that it's not compiler or platform specific.
Unfortunately it does rely on CMake internals to get the job done.

> For the record, my projects build on many different platforms.  This is not a
> gcc-only hack, as several other compilers provide similar functionality.

But you will still have to spend time maintaining cases for different compilers.

> The
> bottom line now is that I can compile my *nix builds twice as fast as my VS8
> Windows builds.  This is quite helpful for *nix users,

Whereas in my case I don't have to do anything special at all on any
platform.  No compiler case magic, nuthin'.  I can reuse what is
reusable on any platform.  The drawback is the method for extracting
object locations can break if Kitware decides to change it.

> and it doesn't cost Windows users anything.

Yes it does.  The development time to do things 2 different ways for
Windows vs. Unix.  A build system like CMake is supposed to
*alleviate* that, not spawn corner cases where you routinely do that.

> I am thoroughly amazed at the combative nature I have witnessed on this
> mailing list.  Quite unprofessional IMHO.

I'm of the mindset that if you're prefacing your solutions with "well
this only works for Unix" then you don't really get what
cross-platform build solutions are about.  "We don't care, we know
we're only going to be messing with Unix" is a valid answer for your
personal needs, I'll admit.  But it's not valid as a best practice to
promote to CMake initiates.  If a FAQ is going to contain that info,
then it should make it clear how you're defeating the cross-platform
capabilities of the build tool.

YES I would like to see CMake handle this automagically.  Then the
angst and gnashing of teeth goes away.  My solution is very easy to
implement, and it's easy for the user to employ, but requires that
Kitware freeze a public interface to the object file locations.  I
don't know if they're willing to do that.


Cheers,
Brandon Van Every