포ㅓ퓨ㅡ튜ㅓㅏㅠ러ㅣ류라뉴유루 륲뎓ㅠㅍnnñq ---------------------------------------- NOthing to do Studio SteppenWolf's Company
[email protected] 2010. 7. 30. 20:50 [email protected] 작성: > Send CMake mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > Subject: Re: [CMake] libraryname decoration > To: "Verweij, Arjen" <[email protected]> > Cc: "[email protected]" <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > On Fri, Jul 30, 2010 at 7:53 AM, Verweij, Arjen <[email protected]> > 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 <[email protected]> > Subject: Re: [CMake] libraryname decoration > To: CMake List <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild <[email protected]> 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 <[email protected]> > Subject: [CMake] Support for multiple components in cpack > To: CMake ML <[email protected]> > Message-ID: > <[email protected]> > 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 <[email protected]> > Subject: Re: [CMake] libraryname decoration > To: Olaf van der Spek <[email protected]> > Cc: CMake List <[email protected]> > Message-ID: <[email protected]> > 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 <[email protected]> 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 <[email protected]> > Subject: Re: [CMake] libraryname decoration > To: [email protected] > Message-ID: <[email protected]> > 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<[email protected]> 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 > > [email protected] > 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 <[email protected]> > Subject: Re: [CMake] libraryname decoration > To: [email protected] > Message-ID: <[email protected]> > 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<[email protected]> 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 > > [email protected] > http://academic.cleardefinition.com/ > > > > ------------------------------ > > _______________________________________________ > CMake mailing list > [email protected] > http://www.cmake.org/mailman/listinfo/cmake > > End of CMake Digest, Vol 75, Issue 121 > ************************************** _______________________________________________ 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
