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 <[EMAIL PROTECTED]> 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@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > > -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake