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

[Nicola Pero]

Hi Helge, thanks for your comments. :-)

I feel it's going to be a long reply - one of my usual long emails - sorry
for that.


> Hi,
> 
> personally I dislike your suggestion. "install" should invoke "all" to 
> ensure consistency. I already see me searching to find out why the hell 
> my (or others) changes aren't reflected in the installation base ;-)

If you are worried about 'install' invoking 'all', you are free to setup
whatever device you want to always make sure that this always happens for
you.  Use a shell script, or a shell alias, or simply add 'install:: all'
to your makefiles, or set the environment variable which will tell
gnustep-make you want this dependency automatically used.

 
> Some more ideas (unstructured):
> 
> - the behaviour is absolutly standard. I've never seen a Unix source 
> which doesn't 'make all' as part of 'make install'. If you do cross-user 
> things, you should be aware about the results.

Thanks for pointing this out - I find that this point is actually the most
convincing one against the change.  The GNU coding standards do say that
'install' implies 'all', and most GNU projects do implement it.  So I'm no
longer completely sure we want this change.

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.

I find it a bit clumsy and inflexible, as if some handy, but specific,
setup which should be at user-level (always running 'all' then 'install'
when building) had been moved inside the basic framework.

If the two targets are separate, it's trivial to write a shell script to
run 'make' followed by 'make install', and then you can use that if you
want to run them together.  Or you could add a alias makei='make;make
install' into your .bashrc ... you could include a standard makefile
fragment of yours containing the single line 'install:: all' ... but other
users (like me) who prefer a different pattern, can have a different
pattern.

If instead the two targets are hardcoded together in the framework itself,
there is no way to break them apart - and all users are forced to use this
pattern ... which is not necessarily appropriate in all situations.

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.

About this, the GNU coding standards say -

"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."

This looks like a hack to me, to somewhat support a different usage
pattern (building as one user, installing as another user, with the two
operations separated) which can not really be supported if install depends
on all.  The 'hack' is that if you spend enough time to write the make
rules in such a way that they strictly do nothing if all is already made,
then doing a 'make install' after a 'make all' will do nothing in the
'make all' part (NB: in some extreme cases, it might be impossible to
write proper rules, and the only way to go is to rebuild things always, so
this trick can't work in all cases anyway).

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.

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).

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.


> - if you know and are allowed to install things as "root" (su -), you 
> should be aware on how to properly compile before and how to fix 
> problems if you didn't (su chown -R me.dev ./obj)

This is not very convincing because:

 - installing things as "root" is the default for newcomers / newbies
installing the basic gnustep packages, it's not a 'special' option for
'advanced' users (typically, it's 'advanced' users such as you who do
*not* install as root).  Most of our users / newcomers / newbies do
install gnustep-make, gnustep-base, gnustep-gui etc as root.  They do a

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

I don't see any other way of letting them compile and install quickly
gnustep from sources; and we can't expect them to be able to manage
problems.  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 ... it
does not conflict with distributing GNUstep as RPMs/DEBs - it's sort of
complementary.

 - the problem with installing things as "root" is not only of annoying
file ownerships, but also that 'make all' often launches GNUstep programs
or scripts, and "root"'s environment might not be set up properly to
launch them (not to say that it's much more secure and safe if you do not
launch them at all if you know it's needed only for building, but not for
installing!).  For many reasons, often problems or mistakes in the
installation or in the system setup, but running GNUstep programs or
scripts as "root" when newbies are at their first GNUstep installation is
an additional complication which we'd be happy to avoid.  Finally, yes
it's much safer if we run as little code as possible as root when newbies,
which are not (yet) understanding what's happening in detail, are at their
first GNUstep installation.

 
> - you should never install things as root since a) identity is lost and 
> b) it isn't necessary in 98% of the cases. IMHO the proper solution is 
> to give the /GNUstep (or better, /GSLocal) permissions that allow you to 
> do installs - most likely by creating a Unix group (eg gsadmin), giving 
> the tree the g+w permission and add trusted accounts to the gsadmin group.
> 
> - Adam said something about RPM. We build all our packages as a normal 
> Unix user. Build-Root is exactly for that. Eg we use a separate GNUstep 
> tree for the %build and for the %install section (and a local RPM 
> database) to get clean builds.
> 
> - I always use RPMs for system-wide installations. during development I 
> always have a user-owned GNUSTEP_SYSTEM_ROOT and therefore never run 
> into the mentioned problem. (the situation where a developer can do 
> make-install as root is not practical in teams +3 people).

Yes - I mean all this is very nice, and I do agree with you, but I don't
see why having 'install' not being hardcoded to forcefully depend on 'all'
would conflict with the (very good) habits you describe.  You can still
get the same behaviour as you always had by running 'make all' then
immediately afterwards 'make install'.  If you have RPM build scripts,
it's trivial to change them to do so.  You can use shell scripts or
aliases to build; if you know you will always use that development
pattern, you can even simply add 'install:: all' to your makefiles.

I would also build a run-time option controlled via a shell environment
variable into gnustep-make, which would automatically add the dependency
'install-->all'.

In short, I think this change would make the framework more flexible by
allowing more valid 'usage patterns'.  You could still do everything you
could do before, but you could do more things.  It would be most
beneficial for newbies I think (making the newbie golden rule 'make; su -c
"make install"' more safe/more certain to work), but it would open more
options for some advanced users (read me) as well.

Anyway - there seem to be different opinions, so I'll need to think and
consider more before/if doing this change. :-)

Comments always welcome.


> 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.

I'm personally waiting eagerly for precompiled headers to be
included/merged into FSF gcc ... :-)

... that would be really cool, and possibly, finally, cut down the
measurable build overhead generated by including almost any AppKit/*.h
under GNUstep (because almost in all cases, this ends up including the
front-end/back-end optimized interface which is a lot of inline functions,
and takes quite some time to compile).