[CMake] libraryname decoration
Olaf, >>> Why? >>> I'm still waiting for someone to post a reason of why a decorated >>> name is a problem for them. >>> Also waiting on an answer to the code duplication issue. Perhaps you should write a proposal that takes care of details, like how you would like to see this decorated. Then write a patch or create a cmake module that takes care of this. I don't see code duplication. Arjen ___ 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
Re: [CMake] libraryname decoration
On 30. Jul, 2010, at 7:53 , Verweij, Arjen wrote:
> Olaf,
>
Why?
I'm still waiting for someone to post a reason of why a decorated
name is a problem for them.
Also waiting on an answer to the code duplication issue.
>
> Perhaps you should write a proposal that takes care of details, like how you
> would like to see this decorated. Then write a patch or create a cmake module
> that takes care of this. I don't see code duplication.
>
> Arjen
First of all: There is almost NO duplication, since almost every project that
does decoration uses different conventions. That's like saying that there is an
enormous amount of code duplication because almost every CMake-based project
calls PROJECT, ADD_LIBRARY and ADD_EXECUTABLE.
Second: It is impossible for CMake do come up with a good decoration scheme
that covers all possible variations. What criteria should enter the decoration?
CMake currently chooses only to offer automatic decoration for debug builds,
which is IMHO a valid choice. Everything else becomes guesswork. Here a list of
possible criteria that sprang to mind, some of which CMake cannot possibly
determine:
* build-type (debug, release, release with debug info, etc.)
* 32/64-bit
* compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
* SDK (e.g. on Mac) or runtime library on Windows
* single/multi-threaded
* integer size (e.g. for array indices, see Intel MKL)
* license differences (e.g. containing non-free code or DFSG-clean)
* capabilities, such as using ncurses, GNU readline or BSD editline (VERY
different),
using cryptographic software or not (e.g. openssl/gnutls)
The list goes on and on, and you simply can't expect CMake to make the right
choice for you (well, it could, but then you would get names that easily exceed
the maximum length for filenames of almost any operating system around and
linking against that library without CMake would be utter pain).
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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 7:53 AM, Verweij, Arjen wrote: > Perhaps you should write a proposal that takes care of details, like how you > would like to see this decorated. Good idea, as not everyone seems to understand my goals. > Then write a patch or create a cmake module that takes care of this. I don't > see code duplication. If I've got 7 independent libs that use the same decoration rules, how do I do this without duplicating those rules in every lib? Olaf ___ 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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
> First of all: There is almost NO duplication, since almost every project that
> does decoration uses different conventions.
Duplication does not mean that the code is 100% equal.
> Second: It is impossible for CMake do come up with a good decoration scheme
> that covers all possible variations.
Why would this optional scheme have to cover every possible variation?
It's like you're saying that because something can't be done
perfectly, nothing should be done at all.
> What criteria should enter the decoration? CMake currently chooses only to
> offer automatic decoration for debug builds, which is IMHO a valid choice.
> Everything else becomes guesswork. Here a list of possible criteria that
> sprang to mind, some of which CMake cannot possibly determine:
>
> * build-type (debug, release, release with debug info, etc.)
> * 32/64-bit
> * compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
> * SDK (e.g. on Mac) or runtime library on Windows
> * single/multi-threaded
> * integer size (e.g. for array indices, see Intel MKL)
Isn't this defined by ABI, just like 32/64 bit?
> * license differences (e.g. containing non-free code or DFSG-clean)
> * capabilities, such as using ncurses, GNU readline or BSD editline (VERY
> different),
> using cryptographic software or not (e.g. openssl/gnutls)
On Windows, at least build type, run-time and platform.
But what should and what should not be part of the name doesn't have
to be fixed. So that's no problem.
> The list goes on and on, and you simply can't expect CMake to make the right
> choice for you (well, it could, but then you would get names that easily
> exceed the maximum length for filenames of almost any operating system around
> and linking against that library without CMake would be utter pain).
MSVC supports auto linking and Boost shows that using it is even
easier then normal linking.
Olaf
___
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
Re: [CMake] libraryname decoration
On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
>> First of all: There is almost NO duplication, since almost every project
>> that does decoration uses different conventions.
>
> Duplication does not mean that the code is 100% equal.
Let's turn this around for once *evilgrin*: Why?
>
>> Second: It is impossible for CMake do come up with a good decoration scheme
>> that covers all possible variations.
>
> Why would this optional scheme have to cover every possible variation?
> It's like you're saying that because something can't be done
> perfectly, nothing should be done at all.
See, there you say it yourself. CMake has already the scheme of adding a debug
suffix. Not perfect, but it's there and it is working. Stop whining and provide
a patch.
>
>> What criteria should enter the decoration? CMake currently chooses only to
>> offer automatic decoration for debug builds, which is IMHO a valid choice.
>> Everything else becomes guesswork. Here a list of possible criteria that
>> sprang to mind, some of which CMake cannot possibly determine:
>>
>> * build-type (debug, release, release with debug info, etc.)
>> * 32/64-bit
>> * compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
>> * SDK (e.g. on Mac) or runtime library on Windows
>> * single/multi-threaded
>> * integer size (e.g. for array indices, see Intel MKL)
>
> Isn't this defined by ABI, just like 32/64 bit?
Not necessarily. The MKL offers the choice of using 32 bit integers (maximum
compatibility) and 64 bit integers (huge arrays).
This is a rather dated/historic document, but it describes the various models.
http://www.unix.org/version2/whatsnew/lp64_wp.html
The MKL supports both, ILP64 and LP64, see this:
http://www.intel.com/software/products/mkl/docs/linux/WebHelp/mkl_ug_structure/support_for_ilp64_programming.htm
>
>> * license differences (e.g. containing non-free code or DFSG-clean)
>> * capabilities, such as using ncurses, GNU readline or BSD editline (VERY
>> different),
>> using cryptographic software or not (e.g. openssl/gnutls)
>
> On Windows, at least build type, run-time and platform.
> But what should and what should not be part of the name doesn't have
> to be fixed. So that's no problem.
Please do explain. How would this work? What would the API be? And now it
suddenly sounds like CMake isn't supposed to do everything automagically
anymore. If that is the case, please RTFM and look into the OUTPUT_NAME target
property. It offers exactly what you want!
>
>> The list goes on and on, and you simply can't expect CMake to make the right
>> choice for you (well, it could, but then you would get names that easily
>> exceed the maximum length for filenames of almost any operating system
>> around and linking against that library without CMake would be utter pain).
>
> MSVC supports auto linking and Boost shows that using it is even
> easier then normal linking.
Why? (See how annoying this is? Normally I expect this kind of
argumentation/questioning from 4-5 year olds...)
To answer partially why I don't think that the boost-way is a solution for
every project, just look at how it's implemented.
http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp
Really cool... THAT's a lot of code that requires a lot of maintenance!
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
Re: [CMake] libraryname decoration
On 7/30/10 6:16 AM, Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
First of all: There is almost NO duplication, since almost every project that
does decoration uses different conventions.
Duplication does not mean that the code is 100% equal.
Second: It is impossible for CMake do come up with a good decoration scheme
that covers all possible variations.
Why would this optional scheme have to cover every possible variation?
It's like you're saying that because something can't be done
perfectly, nothing should be done at all.
What criteria should enter the decoration? CMake currently chooses only to
offer automatic decoration for debug builds, which is IMHO a valid choice.
Everything else becomes guesswork. Here a list of possible criteria that sprang
to mind, some of which CMake cannot possibly determine:
* build-type (debug, release, release with debug info, etc.)
* 32/64-bit
* compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
* SDK (e.g. on Mac) or runtime library on Windows
* single/multi-threaded
* integer size (e.g. for array indices, see Intel MKL)
Isn't this defined by ABI, just like 32/64 bit?
* license differences (e.g. containing non-free code or DFSG-clean)
* capabilities, such as using ncurses, GNU readline or BSD editline (VERY
different),
using cryptographic software or not (e.g. openssl/gnutls)
On Windows, at least build type, run-time and platform.
But what should and what should not be part of the name doesn't have
to be fixed. So that's no problem.
The list goes on and on, and you simply can't expect CMake to make the right
choice for you (well, it could, but then you would get names that easily exceed
the maximum length for filenames of almost any operating system around and
linking against that library without CMake would be utter pain).
MSVC supports auto linking and Boost shows that using it is even
easier then normal linking.
Olaf
If you want to avoid code duplication, write a cmake module that does it
then share it with the world. This doesn't have to be a top-down
solution: if you think you have the best library decoration system
wrapped in a tidy, documented module, then there's nothing stopping you
from publicizing it and encouraging projects (instead of project tools)
to use it. De-facto, not de-jure.
(In general, this is my approach to things I'd like CMake to do that it
doesn't yet, and really, if it doesn't need a core change to be
possible, it's probably the best place for the code. Look in any of my
projects on GitHub, like
http://github.com/rpavlik/physical-modeling-utilities , for:
* CreateLaunchers.cmake
* CreateDashboardScripts.cmake
* CppcheckTargets.cmake
* DoxygenTargets.cmake
* SetDefaultBuildType.cmake
* EnableExtraCompilerWarnings.cmake
to get an idea of how I solve these things - I solve them once in a
module, which makes its way into open source code, and hopefully if
folks want to do similar things they end up finding these modules,
and/or even improving them...)
--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University
rpav...@iastate.edu
http://academic.cleardefinition.com/
___
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
Re: [CMake] libraryname decoration
On 7/30/10 6:45 AM, Michael Wild wrote:
On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
First of all: There is almost NO duplication, since almost every project that
does decoration uses different conventions.
Duplication does not mean that the code is 100% equal.
Let's turn this around for once *evilgrin*: Why?
Second: It is impossible for CMake do come up with a good decoration scheme
that covers all possible variations.
Why would this optional scheme have to cover every possible variation?
It's like you're saying that because something can't be done
perfectly, nothing should be done at all.
See, there you say it yourself. CMake has already the scheme of adding a debug
suffix. Not perfect, but it's there and it is working. Stop whining and provide
a patch.
What criteria should enter the decoration? CMake currently chooses only to
offer automatic decoration for debug builds, which is IMHO a valid choice.
Everything else becomes guesswork. Here a list of possible criteria that sprang
to mind, some of which CMake cannot possibly determine:
* build-type (debug, release, release with debug info, etc.)
* 32/64-bit
* compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
* SDK (e.g. on Mac) or runtime library on Windows
* single/multi-threaded
* integer size (e.g. for array indices, see Intel MKL)
Isn't this defined by ABI, just like 32/64 bit?
Not necessarily. The MKL offers the choice of using 32 bit integers (maximum
compatibility) and 64 bit integers (huge arrays).
This is a rather dated/historic document, but it describes the various models.
http://www.unix.org/version2/whatsnew/lp64_wp.html
The MKL supports both, ILP64 and LP64, see this:
http://www.intel.com/software/products/mkl/docs/linux/WebHelp/mkl_ug_structure/support_for_ilp64_programming.htm
* license differences (e.g. containing non-free code or DFSG-clean)
* capabilities, such as using ncurses, GNU readline or BSD editline (VERY
different),
using cryptographic software or not (e.g. openssl/gnutls)
On Windows, at least build type, run-time and platform.
But what should and what should not be part of the name doesn't have
to be fixed. So that's no problem.
Please do explain. How would this work? What would the API be? And now it
suddenly sounds like CMake isn't supposed to do everything automagically
anymore. If that is the case, please RTFM and look into the OUTPUT_NAME target
property. It offers exactly what you want!
The list goes on and on, and you simply can't expect CMake to make the right
choice for you (well, it could, but then you would get names that easily exceed
the maximum length for filenames of almost any operating system around and
linking against that library without CMake would be utter pain).
MSVC supports auto linking and Boost shows that using it is even
easier then normal linking.
Why? (See how annoying this is? Normally I expect this kind of
argumentation/questioning from 4-5 year olds...)
To answer partially why I don't think that the boost-way is a solution for
every project, just look at how it's implemented.
http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp
Really cool... THAT's a lot of code that requires a lot of maintenance!
Michael
And, if you ask any auto*-using developer how they feel about detecting
and configuring boost, prepare for some impolite words. Even the cmake
module for detecting it is complex.
(and auto-linking appears to only work on windows with MSVC, and I'm not
prepared to let #pragma comment(lib, "mylib.lib") surrounded by ifdefs
sneak into my source code.)
--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University
rpav...@iastate.edu
http://academic.cleardefinition.com/
___
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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 1:45 PM, Michael Wild wrote: > > On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote: > >> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote: >>> First of all: There is almost NO duplication, since almost every project >>> that does decoration uses different conventions. >> >> Duplication does not mean that the code is 100% equal. > > Let's turn this around for once *evilgrin*: Why? If the code is 100% equal there's no problem. Problems arise when you alter one copy but forget to alter other copies. At that point there's inconsistency. >> On Windows, at least build type, run-time and platform. >> But what should and what should not be part of the name doesn't have >> to be fixed. So that's no problem. > > Please do explain. How would this work? What would the API be? I don't know yet. > And now it suddenly sounds like CMake isn't supposed to do everything > automagically anymore. If that is the case, please RTFM and look into the > OUTPUT_NAME target property. It offers exactly what you want! > >> >>> The list goes on and on, and you simply can't expect CMake to make the >>> right choice for you (well, it could, but then you would get names that >>> easily exceed the maximum length for filenames of almost any operating >>> system around and linking against that library without CMake would be utter >>> pain). >> >> MSVC supports auto linking and Boost shows that using it is even >> easier then normal linking. > > Why? (See how annoying this is? Normally I expect this kind of > argumentation/questioning from 4-5 year olds...) Because I don't have to specify the libs to link against myself. > To answer partially why I don't think that the boost-way is a solution for > every project, just look at how it's implemented. > http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp > > Really cool... THAT's a lot of code that requires a lot of maintenance! Why? Yes, it's a lot of code, but why does that imply it requires a lot of maintenance? Olaf ___ 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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 1:45 PM, Ryan Pavlik wrote: > If you want to avoid code duplication, write a cmake module that does it > then share it with the world. This doesn't have to be a top-down solution: > if you think you have the best library decoration system wrapped in a tidy, > documented module, then there's nothing stopping you from publicizing it and > encouraging projects (instead of project tools) to use it. De-facto, not > de-jure. > > (In general, this is my approach to things I'd like CMake to do that it > doesn't yet, and really, if it doesn't need a core change to be possible, > it's probably the best place for the code. Look in any of my projects on > GitHub, like http://github.com/rpavlik/physical-modeling-utilities , for: > > CreateLaunchers.cmake > CreateDashboardScripts.cmake > CppcheckTargets.cmake > DoxygenTargets.cmake > SetDefaultBuildType.cmake > EnableExtraCompilerWarnings.cmake > > to get an idea of how I solve these things - I solve them once in a module, > which makes its way into open source code, and hopefully if folks want to do > similar things they end up finding these modules, and/or even improving > them...) Thanks, I'll have a look. Olaf ___ 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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 1:49 PM, Ryan Pavlik wrote: > And, if you ask any auto*-using developer how they feel about detecting and > configuring boost, prepare for some impolite words. Even the cmake module > for detecting it is complex. > > (and auto-linking appears to only work on windows with MSVC, and I'm not > prepared to let #pragma comment(lib, "mylib.lib") surrounded by ifdefs sneak > into my source code.) It's a shame gcc doesn't support it yet. I would love to see support there. Olaf ___ 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
Re: [CMake] libraryname decoration
On 7/30/10 6:58 AM, Olaf van der Spek wrote: On Fri, Jul 30, 2010 at 1:49 PM, Ryan Pavlik wrote: And, if you ask any auto*-using developer how they feel about detecting and configuring boost, prepare for some impolite words. Even the cmake module for detecting it is complex. (and auto-linking appears to only work on windows with MSVC, and I'm not prepared to let #pragma comment(lib, "mylib.lib") surrounded by ifdefs sneak into my source code.) It's a shame gcc doesn't support it yet. I would love to see support there. Olaf The issue conceptually for me here, is that the code shouldn't/doesn't necessarily know what exact library name to link against - think different versions of libraries, different platforms... What ends up happening in projects that rely on those kinds of constructs, is your config system ends up having to configure a file specifying the library names for the pragmas to work, which ends up being more hassle than just handling linking entirely within the build system. (Plus, then you get the whole "I know exactly what my project links against and uses" benefit.) I use boost a lot. I've only used its auto-linking by accident, when it guesses the wrong decorated name or wrong location for my platform, at which point I realize I missed a library in my build system. It ends up being a slightly more convenient "unresolved symbols" error. Ryan -- Ryan Pavlik Human-Computer Interaction Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com/ ___ 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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 2:05 PM, Ryan Pavlik wrote: >> It's a shame gcc doesn't support it yet. I would love to see support >> there. >> >> Olaf > > The issue conceptually for me here, is that the code shouldn't/doesn't > necessarily know what exact library name to link against - think different > versions of libraries, different platforms... Could you give a concrete example? As, again with Boost, I've never seen an issue like this. > What ends up happening in > projects that rely on those kinds of constructs, is your config system ends > up having to configure a file specifying the library names for the pragmas > to work, which ends up being more hassle than just handling linking entirely > within the build system. (Plus, then you get the whole "I know exactly what > my project links against and uses" benefit.) > I use boost a lot. I've only used its auto-linking by accident, when it > guesses the wrong decorated name or wrong location for my platform, at which > point I realize I missed a library in my build system. It ends up being a > slightly more convenient "unresolved symbols" error. Interesting. What was the cause of this issue? Olaf ___ 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
Re: [CMake] libraryname decoration
On 7/30/10 7:11 AM, Olaf van der Spek wrote: On Fri, Jul 30, 2010 at 2:05 PM, Ryan Pavlik wrote: It's a shame gcc doesn't support it yet. I would love to see support there. Olaf The issue conceptually for me here, is that the code shouldn't/doesn't necessarily know what exact library name to link against - think different versions of libraries, different platforms... Could you give a concrete example? As, again with Boost, I've never seen an issue like this. see starting at line 272 http://github.com/rpavlik/vrpn/blob/master/vrpn_Configure.h What ends up happening in projects that rely on those kinds of constructs, is your config system ends up having to configure a file specifying the library names for the pragmas to work, which ends up being more hassle than just handling linking entirely within the build system. (Plus, then you get the whole "I know exactly what my project links against and uses" benefit.) I use boost a lot. I've only used its auto-linking by accident, when it guesses the wrong decorated name or wrong location for my platform, at which point I realize I missed a library in my build system. It ends up being a slightly more convenient "unresolved symbols" error. Interesting. What was the cause of this issue? Olaf Exactly what I said: when I failed to realize I needed to link a library for one of the boost modules I was using. (If you use the deprecated link_directories command you might not notice this as often, but I've learned that it's the wrong thing to do and that full library paths passed to the linker are the most reliable.) -- Ryan Pavlik Human-Computer Interaction Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com/ ___ 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
Re: [CMake] libraryname decoration
> Please do explain. How would this work? What would the API be? And now it
> suddenly sounds like CMake isn't supposed to do everything automagically
> anymore. If that is the case, please RTFM and look into the OUTPUT_NAME
> target property. It offers exactly what you want!
>
Or the prefix variables.
I have the following in a file called NamingConvention.cmake.
IF(MSVC)
IF(MSVC90)
SET(CMAKE_DEBUG_POSTFIX "_d_2008")
SET(CMAKE_RELEASE_POSTFIX "_2008")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2008")
ENDIF(MSVC90)
IF(MSVC80)
SET(CMAKE_DEBUG_POSTFIX "_d_2005")
SET(CMAKE_RELEASE_POSTFIX "_2005")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2005")
ENDIF(MSVC80)
IF(MSVC71)
SET(CMAKE_DEBUG_POSTFIX "_d_2003")
SET(CMAKE_RELEASE_POSTFIX "_2003")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2003")
ENDIF(MSVC71)
IF(MSVC70)
SET(CMAKE_DEBUG_POSTFIX "_d_2002")
SET(CMAKE_RELEASE_POSTFIX "_2002")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2002")
ENDIF(MSVC70)
IF(MSVC60)
SET(CMAKE_DEBUG_POSTFIX "_d_vc6")
SET(CMAKE_RELEASE_POSTFIX "_vc6")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_vc6")
ENDIF(MSVC60)
#Name 64bit libaraies differenly
IF(CMAKE_SIZEOF_VOID_P MATCHES 8)
SET(CMAKE_DEBUG_POSTFIX "${CMAKE_DEBUG_POSTFIX}_x64")
SET(CMAKE_RELEASE_POSTFIX "${CMAKE_RELEASE_POSTFIX}_x64")
SET(CMAKE_RELWITHDEBINFO_POSTFIX
"${CMAKE_RELWITHDEBINFO_POSTFIX}_x64")
IF(DETECT_64BIT_PORTABILITY)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Wp64")
ENDIF(DETECT_64BIT_PORTABILITY)
ENDIF(CMAKE_SIZEOF_VOID_P MATCHES 8)
ENDIF(MSVC)
To activate the naming convention for any of my projects I just call
include(CMake\NamingConvention.cmake) in the top of my CMakeLists.txt
and my libraries all have decorated names that distinguish between
compiler name and 32/64 bit. If I wanted I could spend 5 minutes and
add gcc and other defined compilers to this.
John
___
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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 2:15 PM, Ryan Pavlik wrote: >>> The issue conceptually for me here, is that the code shouldn't/doesn't >>> necessarily know what exact library name to link against - think >>> different >>> versions of libraries, different platforms... >> >> Could you give a concrete example? As, again with Boost, I've never >> seen an issue like this. > > see starting at line 272 > http://github.com/rpavlik/vrpn/blob/master/vrpn_Configure.h I see sometimes you're using a release lib in a debug build. If that's required, not using auto linking seems like a good option. >>> What ends up happening in >>> projects that rely on those kinds of constructs, is your config system >>> ends >>> up having to configure a file specifying the library names for the >>> pragmas >>> to work, which ends up being more hassle than just handling linking >>> entirely >>> within the build system. (Plus, then you get the whole "I know exactly >>> what >>> my project links against and uses" benefit.) >>> I use boost a lot. I've only used its auto-linking by accident, when it >>> guesses the wrong decorated name or wrong location for my platform, at >>> which >>> point I realize I missed a library in my build system. It ends up being >>> a >>> slightly more convenient "unresolved symbols" error. >> >> Interesting. What was the cause of this issue? >> >> Olaf > > Exactly what I said: when I failed to realize I needed to link a library for > one of the boost modules I was using. > (If you use the deprecated link_directories command you might not notice > this as often, but I've learned that it's the wrong thing to do and that > full library paths passed to the linker are the most reliable.) So you disabled auto linking and then failed to link it manually? How's that a failure of Boost auto linking? Olaf ___ 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
Re: [CMake] libraryname decoration
On 30. Jul, 2010, at 13:54 , Olaf van der Spek wrote: > On Fri, Jul 30, 2010 at 1:45 PM, Michael Wild wrote: >> >> On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote: >> >>> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote: First of all: There is almost NO duplication, since almost every project that does decoration uses different conventions. >>> >>> Duplication does not mean that the code is 100% equal. >> >> Let's turn this around for once *evilgrin*: Why? > > If the code is 100% equal there's no problem. Problems arise when you > alter one copy but forget to alter other copies. At that point there's > inconsistency. Create a module and share it among your projects, possibly with others. If it's any good it might get included in CMake. Although, I suspect that what you want either requires wrapping add_library and add_executable in custom functions or heavy modifications to cmTarget::GetFullNameInternal(). > >>> On Windows, at least build type, run-time and platform. >>> But what should and what should not be part of the name doesn't have >>> to be fixed. So that's no problem. >> >> Please do explain. How would this work? What would the API be? > > I don't know yet. So, how is it no problem then? > >> And now it suddenly sounds like CMake isn't supposed to do everything >> automagically anymore. If that is the case, please RTFM and look into the >> OUTPUT_NAME target property. It offers exactly what you want! ... >> >>> The list goes on and on, and you simply can't expect CMake to make the right choice for you (well, it could, but then you would get names that easily exceed the maximum length for filenames of almost any operating system around and linking against that library without CMake would be utter pain). >>> >>> MSVC supports auto linking and Boost shows that using it is even >>> easier then normal linking. >> >> Why? (See how annoying this is? Normally I expect this kind of >> argumentation/questioning from 4-5 year olds...) > > Because I don't have to specify the libs to link against myself. Yes, you do. Because most people library authors will just refuse to write and maintain an auto_link.hpp > >> To answer partially why I don't think that the boost-way is a solution for >> every project, just look at how it's implemented. >> http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp >> >> Really cool... THAT's a lot of code that requires a lot of maintenance! > > Why? > Yes, it's a lot of code, but why does that imply it requires a lot of > maintenance? 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. 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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 2:25 PM, Michael Wild wrote: > Create a module and share it among your projects, possibly with others. If > it's any good it might get included in CMake. I probably will. On Windows, at least build type, run-time and platform. But what should and what should not be part of the name doesn't have to be fixed. So that's no problem. >>> >>> Please do explain. How would this work? What would the API be? >> >> I don't know yet. > > So, how is it no problem then? Because I'm quite sure it can be solved. >>> Why? (See how annoying this is? Normally I expect this kind of >>> argumentation/questioning from 4-5 year olds...) >> >> Because I don't have to specify the libs to link against myself. > > Yes, you do. Because most people library authors will just refuse to write > and maintain an auto_link.hpp The auto_link you quoted is not library-specific. But it seems you understand why code duplication is bad. So there's no need to maintain such an auto_link file. > 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. See above. Olaf ___ 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
Re: [CMake] libraryname decoration
On 30. Jul, 2010, at 14:16 , John Drescher wrote:
>> Please do explain. How would this work? What would the API be? And now it
>> suddenly sounds like CMake isn't supposed to do everything automagically
>> anymore. If that is the case, please RTFM and look into the OUTPUT_NAME
>> target property. It offers exactly what you want!
>>
>
> Or the prefix variables.
>
> I have the following in a file called NamingConvention.cmake.
>
> IF(MSVC)
>
> IF(MSVC90)
> SET(CMAKE_DEBUG_POSTFIX "_d_2008")
> SET(CMAKE_RELEASE_POSTFIX "_2008")
> SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2008")
> ENDIF(MSVC90)
>
> IF(MSVC80)
> SET(CMAKE_DEBUG_POSTFIX "_d_2005")
> SET(CMAKE_RELEASE_POSTFIX "_2005")
> SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2005")
> ENDIF(MSVC80)
>
> IF(MSVC71)
> SET(CMAKE_DEBUG_POSTFIX "_d_2003")
> SET(CMAKE_RELEASE_POSTFIX "_2003")
> SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2003")
> ENDIF(MSVC71)
>
> IF(MSVC70)
> SET(CMAKE_DEBUG_POSTFIX "_d_2002")
> SET(CMAKE_RELEASE_POSTFIX "_2002")
> SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2002")
> ENDIF(MSVC70)
>
> IF(MSVC60)
> SET(CMAKE_DEBUG_POSTFIX "_d_vc6")
> SET(CMAKE_RELEASE_POSTFIX "_vc6")
> SET(CMAKE_RELWITHDEBINFO_POSTFIX "_vc6")
> ENDIF(MSVC60)
>
> #Name 64bit libaraies differenly
> IF(CMAKE_SIZEOF_VOID_P MATCHES 8)
> SET(CMAKE_DEBUG_POSTFIX "${CMAKE_DEBUG_POSTFIX}_x64")
> SET(CMAKE_RELEASE_POSTFIX "${CMAKE_RELEASE_POSTFIX}_x64")
> SET(CMAKE_RELWITHDEBINFO_POSTFIX
> "${CMAKE_RELWITHDEBINFO_POSTFIX}_x64")
>
> IF(DETECT_64BIT_PORTABILITY)
> SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Wp64")
> ENDIF(DETECT_64BIT_PORTABILITY)
> ENDIF(CMAKE_SIZEOF_VOID_P MATCHES 8)
>
> ENDIF(MSVC)
>
> To activate the naming convention for any of my projects I just call
> include(CMake\NamingConvention.cmake) in the top of my CMakeLists.txt
> and my libraries all have decorated names that distinguish between
> compiler name and 32/64 bit. If I wanted I could spend 5 minutes and
> add gcc and other defined compilers to this.
>
> John
Thanks, finally. Olaf, do you see how simple it is? And this code could be
shortened by a mile:
if(MSVC90)
set(comp_suffix _2008)
elseif(MSVC80)
set(comp_suffix _2005)
elseif(MSVC71)
set(comp_suffix _2003)
elseif(MSVC70)
set(comp_suffix _2002)
elseif(MSVC60)
set(comp_suffix _vc6)
endif()
set(arch_suffix)
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
set(arch_suffix _x64)
# THIS IS SPECIFIC TO JOHN'S PROJECT
if(DETECT_64BIT_PORTABILITY)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Wp64")
endif()
endif()
set(CMAKE_DEBUG_POSTFIX _d${comp_suffix}${arch_suffix})
set(CMAKE_RELEASE_POSTFIX ${comp_suffix}${arch_suffix})
set(CMAKE_RELWITHDEBINFO_POSTFIX ${comp_suffix}${arch_suffix})
set(CMAKE_MINSIZEREL_POSTFIX ${comp_suffix}${arch_suffix})
You can extend this to your hearts content...
___
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
Re: [CMake] libraryname decoration
On 30. Jul, 2010, at 14:31 , Olaf van der Spek wrote: > On Fri, Jul 30, 2010 at 2:25 PM, Michael Wild wrote: >> Create a module and share it among your projects, possibly with others. If >> it's any good it might get included in CMake. > > I probably will. > > On Windows, at least build type, run-time and platform. > But what should and what should not be part of the name doesn't have > to be fixed. So that's no problem. Please do explain. How would this work? What would the API be? >>> >>> I don't know yet. >> >> So, how is it no problem then? > > Because I'm quite sure it can be solved. *sigh*. > Why? (See how annoying this is? Normally I expect this kind of argumentation/questioning from 4-5 year olds...) >>> >>> Because I don't have to specify the libs to link against myself. >> >> Yes, you do. Because most people library authors will just refuse to write >> and maintain an auto_link.hpp > > The auto_link you quoted is not library-specific. But it seems you > understand why code duplication is bad. > So there's no need to maintain such an auto_link file. 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. > >> 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. > > See above. See below (that doesn't need more explanation...) // // select toolset if not defined already: // #ifndef BOOST_LIB_TOOLSET // Note: no compilers before 1200 are supported #if defined(BOOST_MSVC) && (BOOST_MSVC < 1300) # ifdef UNDER_CE // vc6: #define BOOST_LIB_TOOLSET "evc4" # else // vc6: #define BOOST_LIB_TOOLSET "vc6" # endif #elif defined(BOOST_MSVC) && (BOOST_MSVC == 1300) // vc7: # define BOOST_LIB_TOOLSET "vc7" #elif defined(BOOST_MSVC) && (BOOST_MSVC == 1310) // vc71: # define BOOST_LIB_TOOLSET "vc71" #elif defined(BOOST_MSVC) && (BOOST_MSVC == 1400) // vc80: # define BOOST_LIB_TOOLSET "vc80" #elif defined(BOOST_MSVC) && (BOOST_MSVC == 1500) // vc90: # define BOOST_LIB_TOOLSET "vc90" #elif defined(BOOST_MSVC) && (BOOST_MSVC >= 1600) // vc10: # define BOOST_LIB_TOOLSET "vc100" #elif defined(__BORLANDC__) // CBuilder 6: # define BOOST_LIB_TOOLSET "bcb" #elif defined(__ICL) // Intel C++, no version number: # define BOOST_LIB_TOOLSET "iw" #elif defined(__MWERKS__) && (__MWERKS__ <= 0x31FF ) // Metrowerks CodeWarrior 8.x # define BOOST_LIB_TOOLSET "cw8" #elif defined(__MWERKS__) && (__MWERKS__ <= 0x32FF ) // Metrowerks CodeWarrior 9.x # define BOOST_LIB_TOOLSET "cw9" #endif #endif // BOOST_LIB_TOOLSET 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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild 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. >>> 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. Olaf ___ 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
Re: [CMake] libraryname decoration
- Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Jul 30, 2010, at 8:46, Olaf van der Spek wrote: > On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild 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. > 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. > > Olaf > ___ > 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 ___ 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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 7:49 AM, Ryan Pavlik wrote:
> On 7/30/10 6:45 AM, Michael Wild wrote:
>>
>> On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
>>
>>> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
First of all: There is almost NO duplication, since almost every project
that does decoration uses different conventions.
>>>
>>> Duplication does not mean that the code is 100% equal.
>>
>> Let's turn this around for once *evilgrin*: Why?
>>
Second: It is impossible for CMake do come up with a good decoration
scheme that covers all possible variations.
>>>
>>> Why would this optional scheme have to cover every possible variation?
>>> It's like you're saying that because something can't be done
>>> perfectly, nothing should be done at all.
>>
>> See, there you say it yourself. CMake has already the scheme of adding a
>> debug suffix. Not perfect, but it's there and it is working. Stop whining
>> and provide a patch.
>>
What criteria should enter the decoration? CMake currently chooses only
to offer automatic decoration for debug builds, which is IMHO a valid
choice. Everything else becomes guesswork. Here a list of possible criteria
that sprang to mind, some of which CMake cannot possibly determine:
* build-type (debug, release, release with debug info, etc.)
* 32/64-bit
* compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
* SDK (e.g. on Mac) or runtime library on Windows
* single/multi-threaded
* integer size (e.g. for array indices, see Intel MKL)
>>>
>>> Isn't this defined by ABI, just like 32/64 bit?
>>
>> Not necessarily. The MKL offers the choice of using 32 bit integers
>> (maximum compatibility) and 64 bit integers (huge arrays).
>>
>> This is a rather dated/historic document, but it describes the various
>> models.
>> http://www.unix.org/version2/whatsnew/lp64_wp.html
>>
>> The MKL supports both, ILP64 and LP64, see this:
>>
>> http://www.intel.com/software/products/mkl/docs/linux/WebHelp/mkl_ug_structure/support_for_ilp64_programming.htm
>>
* license differences (e.g. containing non-free code or DFSG-clean)
* capabilities, such as using ncurses, GNU readline or BSD editline
(VERY different),
using cryptographic software or not (e.g. openssl/gnutls)
>>>
>>> On Windows, at least build type, run-time and platform.
>>> But what should and what should not be part of the name doesn't have
>>> to be fixed. So that's no problem.
>>
>> Please do explain. How would this work? What would the API be? And now it
>> suddenly sounds like CMake isn't supposed to do everything automagically
>> anymore. If that is the case, please RTFM and look into the OUTPUT_NAME
>> target property. It offers exactly what you want!
>>
The list goes on and on, and you simply can't expect CMake to make the
right choice for you (well, it could, but then you would get names that
easily exceed the maximum length for filenames of almost any operating
system around and linking against that library without CMake would be utter
pain).
>>>
>>> MSVC supports auto linking and Boost shows that using it is even
>>> easier then normal linking.
>>
>> Why? (See how annoying this is? Normally I expect this kind of
>> argumentation/questioning from 4-5 year olds...)
>>
>> To answer partially why I don't think that the boost-way is a solution for
>> every project, just look at how it's implemented.
>> http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp
>>
>> Really cool... THAT's a lot of code that requires a lot of maintenance!
>>
>> Michael
>
> And, if you ask any auto*-using developer how they feel about detecting and
> configuring boost, prepare for some impolite words. Even the cmake module
> for detecting it is complex.
>
> (and auto-linking appears to only work on windows with MSVC, and I'm not
> prepared to let #pragma comment(lib, "mylib.lib") surrounded by ifdefs sneak
> into my source code.)
>
> --
> Ryan Pavlik
> Human-Computer Interaction Graduate Student
> Virtual Reality Applications Center
> Iowa State University
>
> rpav...@iastate.edu
> http://academic.cleardefinition.com/
And what if someone else is using a different naming decoration for
their project than what is in the auto-link headers? Then you have to
update all those headers to your own naming scheme which amounts to a
fork of that project. Which sucks.
Mike Jackson.
___
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
Re: [CMake] libraryname decoration
On 30. Jul, 2010, at 14:46 , Olaf van der Spek wrote: > On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild 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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 2:58 PM, Michael Jackson wrote: > And what if someone else is using a different naming decoration for > their project than what is in the auto-link headers? Then you have to > update all those headers to your own naming scheme which amounts to a > fork of that project. Which sucks. Why would you change the naming scheme of your dependencies? You could just disable auto linking and you're back at where you are now. Olaf ___ 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
Re: [CMake] libraryname decoration
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 wrote: > > On 30. Jul, 2010, at 14:46 , Olaf van der Spek wrote: > > > On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild 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 > ___ 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
Re: [CMake] libraryname decoration
Well let's look at how some things are handled. direct X has multiple version of the same library, and msvcrt (msvcrtd)... these are name mangled things. .NET has moved to keeping seperate directories where everything is exactly the same name. Surely there's more than one paradigm that can be used, but it's up to the developer of the library system... most 'normal' builds of open source projects produce a single build mode - release OR debug OR ...; and they maintain a compatible interface so peices of release code can be built against debug libraries and vice versa; Visual studio and probably eclipse and code blocks can generate multiple builds at the same time, but it turns out that cmake really only spits out one of the modes, since it doesn't re-evalute cmakelists to figure out what the real definitions are for each mode; so really cmake is only producing a single target anyhow. On Fri, Jul 30, 2010 at 6:19 AM, Olaf van der Spek wrote: > On Fri, Jul 30, 2010 at 2:58 PM, Michael Jackson > wrote: >> And what if someone else is using a different naming decoration for >> their project than what is in the auto-link headers? Then you have to >> update all those headers to your own naming scheme which amounts to a >> fork of that project. Which sucks. > > Why would you change the naming scheme of your dependencies? > You could just disable auto linking and you're back at where you are now. > > Olaf > ___ > 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 > ___ 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
Re: [CMake] libraryname decoration
On Fri, Jul 30, 2010 at 5:59 PM, David Cole wrote: > 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 > > - 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 I assumed it would be a fairly trivial thing. Why would it cost so much time/money? Olaf ___ 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
Re: [CMake] libraryname decoration
On 10. Aug, 2010, at 15:15 , Olaf van der Spek wrote: > On Fri, Jul 30, 2010 at 5:59 PM, David Cole wrote: >> 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 >> >> - 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 > > I assumed it would be a fairly trivial thing. > Why would it cost so much time/money? > > Olaf Even if it isn't too complicated, it's expensive. Say, you allocate one person for 3 days to do the implementation plus testing and assume the hour to cost on the order of $125 (many Kitware people having a PhD, adding costs to run the company etc...) you're at $3000. But many here think that such a feature would be quite complicated to implement and would require long discussions on how to do it exactly (e.g. what should the API look like?), so you're probably closer to 2-3 weeks (or even more), boosting the price to $1 or $15000, respectively. Do you have that kind of money for such a small feature, or wouldn't it be preferable to spend the few hours to do it the way I proposed earlier? 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
