[CMake] package_source target?

[Alin M Elena]

On Friday 07 November 2008 11:59:04 cmake-request at cmake.org wrote:
> 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: What does `cross-platform' mean? (Jed Brown)
>    2. Visual Studio debbuging working directory (Christophe Riccio)
>    3. Re: What does `cross-platform' mean? (Mike Arthur)
>    4. Re: What does `cross-platform' mean? (Jed Brown)
>    5. Re: Recursive dependencies and static libraries (Hendrik Sattler)
>    6. Re: What does `cross-platform' mean? (Eric Noulard)
>    7. Re: What does `cross-platform' mean? (Jed Brown)
>    8. Re: What does `cross-platform' mean? (Eric Noulard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 7 Nov 2008 12:02:37 +0100
> From: Jed Brown <jed at 59A2.org>
> Subject: Re: [CMake] What does `cross-platform' mean?
> To: cmake at cmake.org
> Message-ID: <20081107110237.GD20100 at brakk.ethz.ch>
> Content-Type: text/plain; charset="us-ascii"
>
> On Fri 2008-11-07 11:28, Andreas Pakulat wrote:
> > If you run into such problems then open bugreports. Many of the
> > FindXXX.cmake modules have been contributed and most people out there
> > don't have a cluster of different types of machines with different
> > installations of the software at hand. Its quite easy to overlook
> > something and "get it wrong", so if you find errors you need to report
> > them and work with the CMake people on fixing them - or fix them locally
> > in your installation.
>
> Thanks Andreas.
>
> I'm bringing it up here because it isn't so much specific to particular
> modules as it is errors in almost all modules.  This started with me
> learning enough CMake to write my own modules by looking at some of the
> modules distributed with CMake.  Confused that I couldn't find the logic
> dealing with certain issues, I made some test cases and found that every
> module I found would fail in predictable, obvious, and unacceptable
> ways.  Moreover making these modules correct requires some primitives so
> that even the simplest FindXXX module doesn't have to be 100 lines.
> I've only been using CMake for a few weeks, but I offered some
> suggestions on possible primitives here
>
>   http://www.cmake.org/pipermail/cmake/2008-November/025112.html
>
> I had hoped that by raising the issue of widespread brokenness, there
> would be some response from CMake developers about ways to fix it.  It
> seems like I'm still at the stage of convincing people that there is a
> real problem.  This is why I'm concerned that `cross-platform' may
> actually mean `Ubuntu/Windows/Mac' in practice.
>
> BTW, Kitware has a build farm and I had assumed that they would have
> some non-vanilla machines so that at least the modules distributed with
> CMake would be reasonably robust.  To have the build system find these
> bugs, I suggest two configurations which I assume are not present.
> First, a machine with only static libs (almost every non-standalone
> package is broken in this environment).  Second, a machine where
> packages are installed in PREFIX=/usr and PREFIX=/opt/package-name,
> where the user requests the version in /opt/package-name.  Lots of
> modules provide no reliable way to pick the version in /opt/package-name
> short of manually providing full path to every library in the package
> (including recursive dependencies).
>
> Jed
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 197 bytes
> Desc: not available
> URL:
> <http://www.cmake.org/pipermail/cmake/attachments/20081107/8a3187b9/attachm
>ent-0001.pgp>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 7 Nov 2008 11:30:12 +0000
> From: "Christophe Riccio" <g.truc.creation at gmail.com>
> Subject: [CMake] Visual Studio debbuging working directory
> To: cmake at cmake.org
> Message-ID:
> 	<dcdc49fd0811070330o672e5625t2add8c6c79cab0a5 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi!
>
> I'm new to use CMake and I'm still learning how to get what I need.
>
> Is there any variable to setup the debbuging working directory so that when
> I launch the software from Visual Studio it gets the right location for the
> files?
>
> Thanks!
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://www.cmake.org/pipermail/cmake/attachments/20081107/509adf11/attachm
>ent-0001.htm>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 7 Nov 2008 11:32:03 +0000
> From: Mike Arthur <mike at mikearthur.co.uk>
> Subject: Re: [CMake] What does `cross-platform' mean?
> To: cmake at cmake.org
> Message-ID: <200811071132.04029.mike at mikearthur.co.uk>
> Content-Type: text/plain;  charset="iso-8859-15"
>
> On Friday 07 November 2008 11:02:37 Jed Brown wrote:
> > I had hoped that by raising the issue of widespread brokenness, there
> > would be some response from CMake developers about ways to fix it.  It
> > seems like I'm still at the stage of convincing people that there is a
> > real problem.  This is why I'm concerned that `cross-platform' may
> > actually mean `Ubuntu/Windows/Mac' in practice.
>
> I'm no Kitware employee but I do feel the need to defend CMake.
>
> I've used CMake on Debian, Red Hat, Fedora, Slackware, Gentoo, Windows XP,
> Windows Vista, OSX 10.4, OSX 10.5 and custom-rolled Linux distributions.
> I've used it across four architectures and four compilers. I've introduced
> it into two companies I've worked for and use it in my spare-time KDE
> development.
>
> I've never had any of the problems you described.
>
> That's not to say they don't exist but I think you're doing the classic
> software engineer thing (that I've been guilty of more than a few times) of
> assuming your specific circumstances are the norm and that if you have any
> problems then the application is broken for everyone else. This simply
> isn't the case. I haven't seen any of this "widespread brokenness" you
> claim.
>
> You seem to say that CMake doesn't work nicely for a specific use-case you
> have and it may not but there's no need to basically troll the whole
> project because of shortcomings in a niche environment.
>
> CMake may not be perfect but it's the best damned cross-platform build
> system I've seen for C/C++ by a _long_ way.
>
> --
> Cheers,
> Mike Arthur
> http://mikearthur.co.uk/
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 7 Nov 2008 12:40:36 +0100
> From: Jed Brown <jed at 59A2.org>
> Subject: Re: [CMake] What does `cross-platform' mean?
> To: cmake at cmake.org
> Message-ID: <20081107114036.GE20100 at brakk.ethz.ch>
> Content-Type: text/plain; charset="us-ascii"
>
> On Fri 2008-11-07 11:44, Eric Noulard wrote:
> > 2008/11/7 Jed Brown <jed at 59a2.org>:
> > > Are such environments not a goal of CMake?
> >
> > As far as I know there is not so much systems where the simultaneous
> > installation of different version of the same software is cleanly
> > handled.
>
> I agree, it's tricky and often a mess.
>
> > However I don't really think that this is the job of CMake.
>
> [snip]
>
> > My current opinion is the "multiple version" issue should be handle
> > by a "CRAY module"-like tool and not by CMake itself.
> >
> > If the underlying tool is efficient then CMake FIND module should find
> > the appropriate version.
>
> Thank you Eric, this greatly clarifies some design decisions.  May I
> interpret this to mean that CMake does not intend to be concerned with
> finding the `right' version of a library, it is the job of the OS to
> make the system paths find the correct versions?  Thus if CMake finds
> any version of a library, it's assumed correct.  This does make life
> easier for module writers and makes many of my concerns about directory
> paths being parsed incorrectly moot.
>
> Unfortunately not every environment with multiple versions has the
> `module' tool and users will expect to be able to have a reasonable way
> to find specific versions of software.  My development box has 4 MPI
> implementations and 4-16 (ABI-incompatible) versions of many libraries.
> One of these is the default stable version installed by my Linux
> distribution's package manager.  To build against a non-standerd
> version, I should ideally be able to specify one path for each interface
> package (library that my project calls into directly).  That this is
> profoundly broken came as a surprise to me since this is how most other
> automatic configuration packages work (albeit imperfectly).  It's much
> clearer if CMake never intends to support this usage.  With the `module'
> tool, I would load the appropriate modules, run cmake without any
> parameters, and (if the `module'-modules were set up with appropriate
> discipline) get a working build.  I agree that this is nicer for
> everyone (provided `module' is available), but perhaps the CMake
> documentation could be explicit that you need to do something external
> to ensure that `incorrect' versions of libraries cannot be found by the
> system.
>
> Jed
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 197 bytes
> Desc: not available
> URL:
> <http://www.cmake.org/pipermail/cmake/attachments/20081107/dfb55032/attachm
>ent-0001.pgp>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 07 Nov 2008 12:43:42 +0100
> From: Hendrik Sattler <post at hendrik-sattler.de>
> Subject: Re: [CMake] Recursive dependencies and static libraries
> To: cmake at cmake.org
> Message-ID: <491429EE.9050804 at hendrik-sattler.de>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Jed Brown schrieb:
> >>>> The FindPkgConfig.cmake module looks broken too, it assumes that
> >>>>
> >>>>   -L/A -la -L/B -lb
> >>>>
> >>>> is equivalent to
> >>>>
> >>>>   -L/A -L/B -la -lb
> >>>
> >>> I don't see where the above would fail.
> >
> > This can also fail, but I should have written
> >
> >   -L/B -L/A -la -lb
> >
> > since the existing modules are doing two things wrong.  When the
> > compiler parses the link line, it builds a stack of libraries to search.
> > This stack must be searched incrementally.
>
> I'd ask the author of B first, why the H*** he has to use the same
> library name that is already used by A, especially since he uses A.
> That is broken in itself because if you install A and B with the same
> prefix, B is broken.
> If you really need such specific linker behaviour (and who tells you
> that all linkers behave like this?), you actually already messed up.
>
> HS
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 7 Nov 2008 12:45:30 +0100
> From: "Eric Noulard" <eric.noulard at gmail.com>
> Subject: Re: [CMake] What does `cross-platform' mean?
> To: cmake at cmake.org
> Message-ID:
> 	<cbe23c50811070345t207869dag295e773c8e5e5e0f at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2008/11/7 Jed Brown <jed at 59a2.org>:
> >> My current opinion is the "multiple version" issue should be handle
> >> by a "CRAY module"-like tool and not by CMake itself.
> >>
> >> If the underlying tool is efficient then CMake FIND module should find
> >> the appropriate version.
> >
> > Thank you Eric, this greatly clarifies some design decisions.  May I
> > interpret this to mean that CMake does not intend to be concerned with
> > finding the `right' version of a library, it is the job of the OS to
> > make the system paths find the correct versions?
>
> Before reading on your comment I want to tell clearly that I am
> expression MY OWN OPINION regarding CMake design.
>
> I'm a pleased CMake user but not an official CMake developper.
> My word are "only a MY simple user point of view".
>
> That said I'll go on reading your comment
> on come back afterwards.
>
> --
> Erk
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 7 Nov 2008 12:50:04 +0100
> From: Jed Brown <jed at 59A2.org>
> Subject: Re: [CMake] What does `cross-platform' mean?
> To: cmake at cmake.org
> Message-ID: <20081107115004.GF20100 at brakk.ethz.ch>
> Content-Type: text/plain; charset="us-ascii"
>
> On Fri 2008-11-07 11:32, Mike Arthur wrote:
> > I've used CMake on Debian, Red Hat, Fedora, Slackware, Gentoo, Windows
> > XP, Windows Vista, OSX 10.4, OSX 10.5 and custom-rolled Linux
> > distributions. I've used it across four architectures and four compilers.
> > I've introduced it into two companies I've worked for and use it in my
> > spare-time KDE development.
>
> It sounds like these all satisfy the predicate that you have shared libs
> and you only have one version of each package installed (or you're
> trying to find the version in the standard location).
>
> > That's not to say they don't exist but I think you're doing the classic
> > software engineer thing (that I've been guilty of more than a few times)
> > of assuming your specific circumstances are the norm and that if you have
> > any problems then the application is broken for everyone else. This
> > simply isn't the case. I haven't seen any of this "widespread brokenness"
> > you claim.
> >
> > You seem to say that CMake doesn't work nicely for a specific use-case
> > you have and it may not but there's no need to basically troll the whole
> > project because of shortcomings in a niche environment.
> >
> > CMake may not be perfect but it's the best damned cross-platform build
> > system I've seen for C/C++ by a _long_ way.
>
> I really don't intend to bash CMake.  *I* like it much better than the
> alternatives, but I'm trying to convince others and it's hard for me to
> sell CMake while finding that many modules (most of which I don't
> actually care about) are systematically broken in niche environments
> which are disproportionately popular on clusters, an important
> demographic for my projects.
>
> Jed
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 197 bytes
> Desc: not available
> URL:
> <http://www.cmake.org/pipermail/cmake/attachments/20081107/aa19ea68/attachm
>ent-0001.pgp>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 7 Nov 2008 12:57:42 +0100
> From: "Eric Noulard" <eric.noulard at gmail.com>
> Subject: Re: [CMake] What does `cross-platform' mean?
> To: cmake at cmake.org
> Message-ID:
> 	<cbe23c50811070357j6cbf2973x1bb20711ca4f97f5 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2008/11/7 Jed Brown <jed at 59a2.org>:
> >> If the underlying tool is efficient then CMake FIND module should find
> >> the appropriate version.
> >
> > Thank you Eric, this greatly clarifies some design decisions.  May I
> > interpret this to mean that CMake does not intend to be concerned with
> > finding the `right' version of a library,
>
> [...]
>
> ok let's go on with this discussion.
>
> > Unfortunately not every environment with multiple versions has the
> > `module' tool and users will expect to be able to have a reasonable way
> > to find specific versions of software.
>
> I do perfectly understand your point I do remember similar problem
> when I had a patchwork of versions (compiler, lib etc...)
>
> > My development box has 4 MPI
> > implementations and 4-16 (ABI-incompatible) versions of many libraries.
>
> Nice environment indeed :=)
>
> [...]
>
> > It's much clearer if CMake never intends to support this usage.
>
> I think this was not designed for that, just as CMake 2.4 was not
> designed for cross-compiling.
> The need came-in again and again and CMake developpers did
> a good job to make it possible in CMake 2.6.
>
> So not initially designed for it does not meant it won't ever
> be supported.
>
> >  With the `module' tool, I would load the appropriate modules, run cmake
> > without any parameters, and (if the `module'-modules were set up with
> > appropriate discipline) get a working build.  I agree that this is nicer
> > for everyone (provided `module' is available),
>
> My point of view, using the right tool for the right task and avoid
> tool features bloat.
>
> So should we/you put development effort to port/design
> a portable "module tool" or should the needed constrained be
> included in CMake?
>
> I think I did have a look for a  "CRAY module" tool port for linux in the
> past and I did find something but I cannot put the hand on it right now.
>
> > but perhaps the CMake
> > documentation could be explicit that you need to do something external
> > to ensure that `incorrect' versions of libraries cannot be found by the
> > system.
>
> I think you cannot document something which has not been _widely_
> encountered.
Hi,

What happened with the package_source target?

Alin 


-- 
 ______________________________________________________________________
 "...if the universities will not study useless subjects, who will?"
                             G. F. Fitzgerald, Nature, 45/46, 392 (1892)
 ______________________________________________________________________
 Mr. Alin M. ELENA
 Atomistic Simulation Centre
 School of Mathematics and Physics
 Queen's University Belfast
 Office: +44 (0)28 9097 1428
 Fax: +44 (0)28 9097 5359
 http://titus.phy.qub.ac.uk/group/Alin/
 alin.elena at yahoo.co.uk
 alin.elena at qub.ac.uk
 ______________________________________________________________________