On Fri, Aug 20, 2010 at 8:40 AM, Mike McQuaid <m...@mikemcquaid.com> wrote:
> > On 20 Aug 2010, at 13:09, David Cole wrote: > > > Sorry about that. The name was chosen when the functionality was > Mac-only, then we extended it to cover Windows/Linux. What name would you > suggest as "more discoverable" or "better"? > > I'd go for "InstallPrerequisites" personally, it seems to fit in with the > GetPrerequisites vocabulary. > That sounds like a reasonable name. > > > Well, since it needs all the files to exist at analysis time, such a > command would have to generate code that is run at install time. I'd be > surprised if you could easily generalize this such that a client project > would not have to customize it at all, but I could be wrong... > > It would just be a matter of basically calling get_prerequisites or > fixup_bundle (as you already do from CMake) but this generates install-time > code. > > If you think it would be hard to do I could write a little proof of concept > that you could look at? > I don't necessarily think it would be hard to write the basic thing. But it would be great to have your proof of concept code to talk about / base work on... > > > I'm not a big fan of making all this stuff "too automatic" (which is a > completely subjective judgment call, but still...) -- because I think it's a > good thing that developers have to be aware of all the dependencies in their > code. If we make this completely automatic, people will blame CMake when > they inadvertently pull in some GPL-ed component that they don't really > *want* to depend on. Pushing the work onto the end-developer has the nice > side effect of placing the responsibility for such inclusions directly on > the end-developer. (Which is where it belongs.) > > I do get the desire to make things not too automatic (I think this could be > helped by perhaps ensuring that all the prerequisites are printed out even > in cpack's non-verbose mode) but I do think making the syntax similar is > good. Basically, I'm not proposing anything be any more automatic, just that > when I want to, say, get and install all the prerequisites I need to write > less code and, particularly, avoid having to use INSTALL(CODE or SCRIPT) > where the escaping tends to result in many subtle bugs and is hard to debug. > Writing less code is good. If everybody already has substantially similar code in the cmake using projects out there in the real world, then that's a fairly good argument for saying it should be centralized and provided in cmake itself. It would be nice to write less code to get this stuff to work. > > > Not a big fan of this one either. Personally, I think it's stupid even to > have differences between the build tree and the install tree. Now, with > this, you'd have differences between the "make install" tree and the > packaged install tree...? Why do you do this? Just to save devs some time at > "make install" time? Or is there some other valid technical reason that my > foggy morning brain isn't thinking of...? > > I tend to lean towards agreeing with you between install and build time, I > think they should be the same. The thing for make install is that there's > normally three use-cases here for open-source projects (this makes less > sense for proprietary products): > > 1) Developer is building and editing code on their machine: in this case > they will just use "make" and expect things to work from the build directory > (I've filed bugs about this before, being issues with the PATH not being > found/set for instance). In this case, the developer will have all the > necessary libraries installed on their system. > > 2) A user downloads the source (for a tarball or version control) and uses > "make install" to build everything and install it to the correct location > for their personal use on that machine. In this case, they will have all the > necessary libraries already installed and wouldn't expect them to be > installed to that prefix. > > 3) A developer or user creates a binary package for distribution. In this > case, they will have the various libraries already on their system but the > end-user of the package won't. As a result, they will want to ensure that > these are all distributed. > > In short, the difference between 2) and 3) only really matters for > open-source projects but is the difference between installing from source or > binary packages. > Again, thanks for the discussion. Looking forward to where this is headed..... :-) David > > -- > Cheers, > Mike McQuaid > http://mikemcquaid.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
