[CMake] BundleUtilities naming and easing packaging

[David Cole]

On Fri, Aug 20, 2010 at 8:40 AM, Mike McQuaid <mike at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100820/7deda10c/attachment.htm>