|
| From: | Richard Frith-Macdonald |
| Subject: | Re: make sysinstall/Makefile.preamble/GNUSTEP_INSTALLATION_DOMAIN |
| Date: | Fri, 19 Dec 2008 10:54:05 +0000 |
On 19 Dec 2008, at 10:18, Nicola Pero wrote:
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 smallerlist, 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 ;-)
Yes, well that's my preferred option ... I only suggest the alternative as a solution for people who don't like the idea of doing it themselves.
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 completebefore typing the next one (I hate that). ;-) I mean it's trivial to write such a script ... cd core/base ./configure make make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM cd .. cd core/gui ./configure make make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM cd .. ... etc ...I suppose the 'make install' having to be done as root might create a mild complication, but not somethingthat would really deter a serious scripter.Shall we concentrate our work on providing template build scripts then ? I saw that Gregory made improvementsto the core/compile-all script - maybe that's the way to go.
I suspect that the single build script solution is not what people want ... I guess they want to (for example) just build/install one project at a time. They can't be bothered to type 'make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM' and can't be bothered to set up an alias to do that for them. Fundamentally we are wasting hours in discussing this because it's in the nature of human beings to be habit-ridden and therefore basically opposed to changing what they do in any respect whatsoever. I admit to feeling the same about it until I 'bought in' to the idea of making the build/install process as 'safe' for newbies as possible, and accepted that a tiny change in my operating practices was worthwhile to help popularise GNUstep. For people who have no interest in popularising the project, this can't be convincing and they will basically want everything to continue behaving exactly as it has before.
So, you have to consider how much effort it's worth making to address the issues of a tiny minority. Of those issues, I only recall two that made any objective sense (ie some rationale beyond the 'i have to change my habit' one). Fred wanted to keep things in the SYSTEM domain for testing purposes ... to make sure core stuff continues to work when installed there. David wanted to be able to delete LOCAL to get rid of local stuff without effecting the system.
In both of these cases an alias ought to work pretty well, and if you forget to use the alias and accidentally install in LOCAL when you wanted system, well you can just delete the LOCAL domain and do it again. To me, the downside of this just doesn't justify adding complexity to make and the core packages, but if this is what you want to avoid then a record (within the make system) of where you want to install each project seems the only way to go. The make system could manage it automatically so that when you install a project (without explicitly setting a domain) it uses the installation domain last set when you installed that project.
| [Prev in Thread] | Current Thread | [Next in Thread] |