[CMake] libraryname decoration

David Cole david.cole at kitware.com
Fri Jul 30 11:59:59 EDT 2010


Let's keep things calm, reasonable, rational here on the CMake mailing list.
It's a discussion. Some discussions require more patience than others... :-)

Olaf, clearly you have an idea that you are passionate about.

Just as clearly, most of the other responders to this topic have reasons to
be biased against the idea of automatic library name decoration.

Here are the facts, as I see them:
- It would be possible to add automatic opt-in (not enabled by default)
library name decoration rules to CMake
- It would NOT be possible to come up with a naming scheme that is
acceptable to everyone
- Some people love auto-linking from header files, some people hate it

- If the CMake team were to implement such a feature:
-- it would save Olaf from having to do it himself
-- it would take the CMake team a boat-load of time and money and effort to
implement the feature

For those reasons, I do not see this feature happening anytime soon unless
somebody steps up to the plate with:
- a reasonable design for it, acceptable by the consensus of folks right
here on this mailing list
- an implementation patch, fully tested **or** a contract with somebody
(Kitware, cough, cough) to pay them to implement it

I truly hope this clarifies things for you Olaf.

It's not that we are absolutely opposed to such a feature. But please
recognize that it's a large amount of effort to implement it, make sure it's
tested and works on all platforms, and keep it working moving forward.
Especially hard to achieve without consensus...


Thanks,
David Cole
Kitware, Inc.


On Fri, Jul 30, 2010 at 9:08 AM, Michael Wild <themiwi at gmail.com> wrote:

>
> On 30. Jul, 2010, at 14:46 , Olaf van der Spek wrote:
>
> > On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild <themiwi at gmail.com> wrote:
> >> Oh, it IS library specific. Where do you think all these BOOST_MSVC and
> what not come from? It is very specific to Boost. No other project will be
> able to use this without heavy reworking.
> >
> > That's just the MSVC version, available as _MSC_VER by default.
>
> Oh bugger, you really are immune to reason...
>
> 1. This is not the only macro.
> 2. A library project wanting to distribute a similar file has to do a lot
> of work to adapt it to its own requirements.
> 3. It is a maintenance nightmare, because e.g. _MSC_VER is combined from
> the major and minor version number of the compiler, so for VS 2010 it is
> 1600. This requires that for every new version you'll be adding a new branch
> in the #if ... #elif ... #endif maze, translating that number into a
> readable name. Now, imagine other compilers starting to adopt this "magic",
> this file would just explode (and compilation would probably slow down to a
> crawl).
>
> >
> >>>> For every new version of MSVC, Xcode etc. you have to update the file.
> Usually you will be lagging behind, and your users even more so. And then
> they will complain. To you.
> >
> > Only if you include the toolset in the name.
>
> This is really wearing my patience right now. I suggest we stop this
> absolutely futile discussion and let Olaf come up with something
> constructive for once (such as a patch). At least I will.
>
> Michael
> _______________________________________________
> 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/20100730/bfd26c04/attachment-0001.htm>


More information about the CMake mailing list