[CMake] faq update?

[Juan Sanchez]

Hello Brandon,

At the end of the day.  The question I answered was frequently asked on
the mailing list (according to google), and inaccurately answered in the
FAQ.

This issue is a concern for many people, and at least one other person
found it helpful.

While beyond my capabilities, I think a cmake macro which does the right
thing for all working platforms would be helpful.  Barring, that, I
think I have presented a practical solution.

Regards,

Juan

Brandon Van Every wrote:
> 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
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 
> 


-- 
Juan Sanchez
Juan.Sanchez at amd.com
800-538-8450 Ext. 54395
512-602-4395