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 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 ;-)
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 complete
before 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 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.
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.
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
