Am Freitag, den 12.12.2008, 16:42 -0600 schrieb Stefan Bidigaray:
On Fri, Dec 12, 2008 at 2:55 PM, David Chisnall <theraven@sucs.org>
wrote:
On 12 Dec 2008, at 20:58, Fred Kiefer wrote:
And we really should add that "make sysinstall" hack
to GNUstep make
before the next release to make live easier for the
people out that that
want to stick with the old structure.
Please do! Being able to blow away Local without destroying
the GNUstep install is really useful for testing. Before
GNUstep started installing itself in the wrong place, I used
to do this every couple of weeks to make sure clean builds of
Étoilé worked on my machine.
Well, this really doesn't affect me since I've been using
GNUSTEP_INSTALLATION_DOMAIN for a while now, anyway. I'm still not
convinced adding a new target is the right thing to do, and even if
it's implemented by the next release I'll probably still use the
current mechanism. But that's not here or there.
The ability to delete "Local" without deleting the "core" packages
(whatever that may mean to any particular developer) sounds like a
reasonable request. But in my view a -make target like "sysinstall"
doesn't seem like the right approach.
Since it's a developer request, it seems to me that a reasonable
approach would be to have a local (not in svn) Makefile.preamble
having
GNUSTEP_INSTALLATION_DOMAIN set to SYSTEM. That way each developer
can
define which package he believes should be installed into the System
domain. In fact, depending on the current development tree, he can
define it according to his current project and doesn't need to
remember
when to type make install vs. make sysinstall during the development
process.
What I'm not sure about is if that works reliably since
Makefile.preamble get included rather late and I'm not sure how our
usage of "recursively expanded" vs. "Simply expanded" make variables
an
shell invocations of -make would currently allow this to work
reliably.
But I would be interested if those of you currently requesting the
"sysintall" target would prefer the Makefile.preamble approach.