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. > 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'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. > 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. -- 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
