gnustep-dev
[Top][All Lists]
Advanced

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

Re: removing the 'make install'-->'make all' dependency


From: Helge Hess
Subject: Re: removing the 'make install'-->'make all' dependency
Date: Wed, 11 Dec 2002 16:03:57 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021201

Hi,

before commenting things: I'm not in general against the change, of course things could be updated to do a make all by themselves. I just fail to see what the problem is and I don't really believe that this is a problem of newbies in practice.

Nicola Pero wrote:
Even if ... even if I still think that technically this dependency is
wrong.  'Compiling' (generating the files from the sources) and
'installing' (copying the files into the installation dirs) are separated
tasks.  The system is much more flexible if you have the option of running
only one of those two stages, or both of them, at your choice.  If instead
'installing' always implies 'compiling', this flexibility is lost as there
is no way to perform the installation step without the compilation step.

It is true that installing is a different process from compilation. But it depends on a successful compilation, nothing more is expressed by "install : all".
We actually use make to guarantee dependencies, right ? ;-)

I would suggest that you just create an "install-only" target. install can then depend on "install : all install-only". IMHO this would best match current practice. "install" works as with any source package and for people which really only want to install (which IMHO *is* dangerous), use "install-only".

Why start teaching people to do "./configure;make all;make install" if "./configure;make install" used to work ?

Unfortunately, the situation where this pattern is not appropriate is also
the most common for newbies/newcomers to gnustep.  We would love if
newbies/newcomers at their first gnustep installation would be able to run
the compilation stage (only) as a normal user, and the installation stage
(only) as root, as that's more likely to work, and it's also more safe,
since much less code is executed as root.

I fail to see the difference. Removing "all" from "install" is only limiting and doesn't give anything ?

Setup using "install:all" with multiple-users:
make all
su - make install

without "all":
make all
su - make install

"If possible, write the install target rule so that it does not modify
anything in the directory where the program was built, provided `make all'
has just been done. This is convenient for building the program under one
user name and installing it under another."

Exactly.

Anyway, if we are to keep the dependency 'install'-->'all', then we need
to take this point very seriously, at least for gnustep-make internal
rules -- if you type 'make all' twice, the second time *nothing* should be
executed.

Of course ?! This is what make is used for. What do you have in mind that could change ?

BTW: RPM has exactly the same "guidelines": %build builds everything and %install only installs things without further building (this way you can debug the install process without a build environment).

That will require adding proper dependencies for 'plmerge' and all other
scripts.  At the moment 'plmerge' is always run when 'all' is executed,
which is not right (and which I want to fix anyway, but might require
serious changes to the makefile API).

If this is the case, it's a bug ;-)

Unfortunately, it won't help people who like to quickly add scripts or
programs to GNUmakefile.postamble and don't have time to write proper make
rules for them.

This is a very mood point, IMHO. Either you write correct programs or not.

./configure; make; su -c 'make install'

I don't see any other way of letting them compile and install quickly
gnustep from sources;

As I said, they usually will do:
---
su - root
./configure
make install
---
Any newbie will need to do the same procedure with any other GNU tool (eg glib or gtk).

and we can't expect them to be able to manage
problems.

OK. What are the problems ? If they *follow* the install instruction

./configure;make;su -c 'make install'

and the makefiles are according to the standards, they will have no problem with a ".o owned by root" since "install:all" is 100% compatible.
If they don't they will get problems in any case.

> Things should just work out of the box for them.  Every
newcomers whose installation doesn't work out of the box is a potential
GNUstep supporter/user/contributor lost.  I already know your reply will
be that ... that they should be installing RPMs/DEBs and not from sources
:-).  I agree with that, and yet making installation from source code
easier is a good thing to do, and will definitely help newcomers ...

I don't disagree, but IMHO the "problems" you mentioned are no problems in practice. Personally I have the impression that this is more a problem for individual *core* developers that use the HEAD repository to update their whole system and not for newbies.

BTW: did anyone consider adding compiler_cache as a standard feature to GNUstep-make ?

I've never tried using a compiler-cache, but looking on the web, I think
you can just replace your standard compiler with a caching wrapper, and no
changes to gnustep-make is required.

Yes, but this requires errorprone modification of the system. If it would be part of gstep-make, one could say "make debug=yes cache=yes" which would be nice :-)
But it isn't important, would be a nice goodie.

Greetings
  Helge




reply via email to

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