[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make sysinstall/Makefile.preamble/GNUSTEP_INSTALLATION_DOMAIN

From: Nicola Pero
Subject: Re: make sysinstall/Makefile.preamble/GNUSTEP_INSTALLATION_DOMAIN
Date: Fri, 19 Dec 2008 10:18:08 +0000

Let me know if there is any agreement on other pieces of software to include. Maybe we should include everything that is in the GNUstep subversion repository ? I was hoping for a smaller
list, but at least that would provide an objective way to decide.

I'm not in favor of this really for any packages ... I'd like not to have support for this cluttering anything.
Admittedly the clutter is really trivial, but I see no benefit to it.

Sorry ... too short.

What I suggest is:
1. Unwind any changes to any packages to do with this ... intrusive changes to packages merely to support a installation location makes little sense. 2. Produce a different mechanism if you really want a mechanism for this at all.

For instance, you could have a file listing the projects you want to install in the system domain, and gnustep-make could consult that file to decide where to install each project ... eg. if it's got to install a project X, it ooks up X in it's config file, and if it should you in domain Y then it sets GNUSTEP_INSTALLATION_DOMAIN to Y before proceeding. This would avoid the issue of having to decide which projects are 'core' (which is not something the developer/maintainer of the project should be doing).

Yes ... I'm kind of unconvinced myself - even if the changes do implement exactly what was requested (ie, a "backwards-compatibility" mode where 'core' packages get installed into System in the same way as before). I'm kind of accepting that I don't really understand why people really need such a "backwards-compatibility" mode but we're providing it as a temporary measure while our hardcore developers digest the change and hopefully find more logical ways of building/organizing their local installations. ;-)

I like the idea of having a list of 'core' packages that each developer can set up and maintain ... but then well they could as well just set up and maintain a build script then, and we wouldn't even be having this discussion ;-)

A script is much more handy in that it also builds things for you. I can't believe people are really rebuilding everything often and typing './configure; make; make install' manually for all the projects each time - including waiting for each command to complete
before typing the next one (I hate that). ;-)

I mean it's trivial to write such a script ...

 cd core/base
 cd ..

 cd core/gui
 cd ..

 ... etc ...

I suppose the 'make install' having to be done as root might create a mild complication, but not something
that would really deter a serious scripter.

Shall we concentrate our work on providing template build scripts then ? I saw that Gregory made improvements
to the core/compile-all script - maybe that's the way to go.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]