[GRASS5] Re: [GRASSLIST:1299] Re: Grass 5b10 make clean

[Eric G . Miller]

On Wed, Dec 27, 2000 at 04:15:10PM +0700, Justin Hickey wrote:
> Hmmm. I'm not sure what you mean by "fully built". Do you mean that the
> OBJ.$ARCH should contain not only the object files but also the
> executable? If not, then ignore the rest of this paragraph (and most of
> this post for that matter). If so, then grass would not be able to run
> without running "make install" first. The way I set up the Makefile, a
> user can compile grass and then run it, without needing to run "make
> install". This is the typical way most open source software is compiled.
> That is, you run configure, then make, and at this point the user can
> run the program. As I understand it, the idea behind this set up was
> that a user that does not have root access can compile and run the
> program to try it out. If he/she thinks the program is useful to other
> users on the system he/she contacts the sysadmin and requests that the
> sysadmin run "make install". If you need root access to set up the
> executables for execution, then it is not convenient for sysadmins that
> manage hundreds of users. As I said, this is only how I understand it,
> please let me know if this is different from your understanding.

Yes, I was thinking of the full executable under OBJ.$ARCH, but I think
what you describe sounds good too.

> I really like this idea but I would recommend that this be discussed as
> part of the new Makefile system for 5.1, at least that is when it should
> be implemented.
> 
> I think this would be a useful feature, however, "make install" from the
> SRCDIR would have to call each Makefile under it to do a complete
> installation. It should not have a separate functionality. That is, for
> a particular module, it's own "make install" will always install it to
> the installation directories regardless if you are installing only that
> module, or if you are installing all of grass. No other Makefile should
> install the module. And of course, "make uninstall" will have to be
> handled in the same way. Is this what you had in mind?

Yes, that's what I was thinking.  It would require a bit more work than
we probably want to mess with at the moment (until 5.1 becomes active).


> This is not quite the way I see it. What about something like 
> 
> ------------------------------------------------
> OBJS = foo.o bar.o
> 
> LIBES = $(GISLIB)
> 
> PGM = $(BIN_MAIN)/foobar
> 
> $(PGM): $(LIBES) foobar.h
>         $(CC) -o $@ $(LDFLAGS) $(OBJS) $(LIBES) $(MATHLIB) $(XDRLIB) 
> 
> $(GISLIB): #
> 
> install:
>         # Some kind of check to see if we have write permission in
> 	# $(INST_DIR) since we may need root permission and a check to
> 	# to see if $(PGM) exists
> 	cp $(PGM) $(INST_DIR)/$(PGM)
> -------------------------------------------------
> 
> This is basically the same as most Gmakefiles now with the addition of
> the install target. The main difference from your suggestion is that
> $(BIN_MAIN) is not the installation directory, but a "distribution"
> directory under $SRCDIR, while $(INST_DIR) is the installation
> directory. For example

Well, I used $(BIN_MAIN) as an example for the install target because
the "make install" would place the executable, library, or whatever in
its final destination directory.  Also, it's my understanding that using
$(INSTALL) is prefferable to "cp" for conversions to package management
systems (RPM, .deb, whatever).  $(INSTALL) also becomes necessary should
we get libtool setup to build shared libes instead of building
everything statically.

> Note that another difference is that I do not have a make dependency on
> $PGM for the install target. Instead, I would check for it's existance
> as part of the install target. The reason for this is that in general,
> user root should not compile software (this is only my understanding and
> experience). Thus if you type make install as root, you do not want to
> compile the code if it does not exist. In other words, nothing should be
> compiled if you type "make install". The only action that should occur
> is the copying of files. Again, this is how I have understood the
> typical action of "make install" in other open source programs.

I would think make would not recompile the target unless the
dependencies had a newer timestamp (regardless of whether it was
compiled by root or a regular user).  I don't think it's our
responsibility to force users not to compile grass as root by making it
fail arbitrarily if the user is root.

> All "make install" does is copy the files from $GISBASE to $INST_DIR and
> the three executables in $GRASS_BIN to $BINDIR. The only tricky part is
> changing the value of GISBASE inside the $BINDIR/grass5 startup script
> to point to $INST_DIR instead of $GISBASE. Note that the current
> Makefile.in does this substitution.

Yes, that's all that "make install" should do, iff all the build targets
are up to date.  Otherwise, it should also perform any compilation
necessary to bring such targets up to date before performing the
"install" part.  As you mention, this is where your scheme get's tricky
because it's necessary to have different values for $GISBASE.  But, I
suppose it's nice to be able to put GRASS through a trial run before
full installation.  I think it's fair to say that GRASS is different
than many programs because it needs a whole "environment" to work.
Because of that, as you know, you can't just do ./g.manual or something
and expect it to work.  So, I'm not really worried that it needs to be
possible to test run the GRASS environment before placing all the
executables and friends into the install directory structure.  After
all, a person could make the install dir be $HOME/grass5, with the
bindir startup in $HOME/bin.  That would do the same thing, without
requiring root priveledges.

-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'