[CMake] CMake Digest, Vol 75, Issue 121
YongWu Choi
amugana at gmail.com
Sat Jul 31 04:49:50 EDT 2010
포ㅓ퓨ㅡ튜ㅓㅏㅠ러ㅣ류라뉴유루 륲뎓ㅠㅍnnñq
----------------------------------------
NOthing to do Studio
SteppenWolf's Company
amugana at gmail.com
2010. 7. 30. 20:50 cmake-request at cmake.org 작성:
> Send CMake mailing list submissions to
> cmake at cmake.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.cmake.org/mailman/listinfo/cmake
> or, via email, send a message with subject or body 'help' to
> cmake-request at cmake.org
>
> You can reach the person managing the list at
> cmake-owner at cmake.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CMake digest..."
>
>
> Today's Topics:
>
> 1. Re: libraryname decoration (Olaf van der Spek)
> 2. Re: libraryname decoration (Olaf van der Spek)
> 3. Support for multiple components in cpack (Eric Noulard)
> 4. Re: libraryname decoration (Michael Wild)
> 5. Re: libraryname decoration (Ryan Pavlik)
> 6. Re: libraryname decoration (Ryan Pavlik)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 30 Jul 2010 13:08:38 +0200
> From: Olaf van der Spek <olafvdspek at gmail.com>
> Subject: Re: [CMake] libraryname decoration
> To: "Verweij, Arjen" <VerweijA at tass-safe.com>
> Cc: "cmake at cmake.org" <cmake at cmake.org>
> Message-ID:
> <AANLkTinWNuB3SZ0eMP2JTCr4ObcDe-JK-Ko7a9YnW9HE at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Jul 30, 2010 at 7:53 AM, Verweij, Arjen <VerweijA at tass-safe.com> 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
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 30 Jul 2010 13:16:56 +0200
> From: Olaf van der Spek <olafvdspek at gmail.com>
> Subject: Re: [CMake] libraryname decoration
> To: CMake List <cmake at cmake.org>
> Message-ID:
> <AANLkTikpN1_MPxbWjmAyoe-bBBayP4-CBefdUzt92UFx at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild <themiwi at gmail.com> 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
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 30 Jul 2010 13:35:56 +0200
> From: Eric Noulard <eric.noulard at gmail.com>
> Subject: [CMake] Support for multiple components in cpack
> To: CMake ML <cmake at cmake.org>
> Message-ID:
> <AANLkTi=n39CTD5yBpvcN0A5b8hmUYx=mv7QPCPh_PGeV at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi All,
> I'll try to launch a specific thread for this following what
>
> Kishore said:
>> I would like to see full support for multiple components in cpack.
>
> David answered:
>> Could you elaborate on "full support for multiple components in cpack" either in another thread,
>> or in a feature request bug in the bug tracker?
>>
>> With NSIS on Windows and PackageMaker on Mac, we already have what I would consider "full support". Are you talking about
>> extending that to additional CPack generators or is there something missing even in those generators in your opinion?
>
> An explanation on CPack Component may be found here:
> http://www.itk.org/Wiki/CMake:Component_Install_With_CPack
>
> As David said currently the only 2 CPack generators which support Components are
> - NSIS
> - PackageMaker
>
> I personally would like a wider support including RPM, DEB, TGZ (and
> may be ZIP and other archive-like).
> There is at least one bug/feature report/request for that for CPackRPM:
> http://public.kitware.com/Bug/view.php?id=7645
>
>> From my point of view for the RPM/DEB/archive (TBZ2 TGZ TZ ZIP)
> COMPONENT installer there is two "global" options:
>
> A) Put all the components in a single archive with some hierarchical
> structure inside
> i.e. build a TGZ whose structure may be;
> toplevel-name/component1/...
> /component2/...
> etc...
>
> B) Build as many files as components.
> toplevel-name-component1.tgz
> toplevel-name-component2.tgz
> toplevel-name-component3.tgz
>
> The scheme A) is not quite usable for RPM or DEB
> but it is ok for "pure" archive like TBZ2 , TGZ, TZ, ZIP.
>
> My **personal** opinion is that for this kind of installers I'd rather
> go for B).
> The current problem with B) is that current CPack architecture does
> not authorize it see:
> http://public.kitware.com/Bug/view.php?id=10736
>
> Like I said in another mail if we tackle the "multiple file problem" we should
> be able to solve the "naming convention problem" too, see:
> http://public.kitware.com/Bug/view.php?id=9900
>
> So I would like those 2 bugs (9900, 10736)
> solved, which would enable the may-be-easy creation
> of full support for CPack COMPONENTs in any case (including bug 7645).
>
> Please comment on those ideas or indicate whether if you agree with my
> analysis or not.
> Once we have some opinions ideas on this, I'll propose a new/updated
> API for CPack generators
> concerning this.
>
> --
> Erk
> Membre de l'April - ? promouvoir et d?fendre le logiciel libre ? -
> http://www.april.org
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 30 Jul 2010 13:45:04 +0200
> From: Michael Wild <themiwi at gmail.com>
> Subject: Re: [CMake] libraryname decoration
> To: Olaf van der Spek <olafvdspek at gmail.com>
> Cc: CMake List <cmake at cmake.org>
> Message-ID: <CD889442-F600-4DCA-8AB1-A925BF5BC99D at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
>
>> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild <themiwi at gmail.com> 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
>
> ------------------------------
>
> Message: 5
> Date: Fri, 30 Jul 2010 06:45:41 -0500
> From: Ryan Pavlik <rpavlik at iastate.edu>
> Subject: Re: [CMake] libraryname decoration
> To: cmake at cmake.org
> Message-ID: <4C52BB65.7040903 at iastate.edu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 7/30/10 6:16 AM, Olaf van der Spek wrote:
>> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild<themiwi at gmail.com> 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
>
> rpavlik at iastate.edu
> http://academic.cleardefinition.com/
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.cmake.org/pipermail/cmake/attachments/20100730/15ccf507/attachment-0001.htm>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 30 Jul 2010 06:49:50 -0500
> From: Ryan Pavlik <rpavlik at iastate.edu>
> Subject: Re: [CMake] libraryname decoration
> To: cmake at cmake.org
> Message-ID: <4C52BC5E.1020603 at iastate.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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<themiwi at gmail.com> 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
>
> rpavlik at iastate.edu
> http://academic.cleardefinition.com/
>
>
>
> ------------------------------
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
> End of CMake Digest, Vol 75, Issue 121
> **************************************
More information about the CMake
mailing list