[GRASS5] Re: [GRASSLIST:1299] Re: Grass 5b10 make clean
jhickey at hpcc.nectec.or.th
Wed Dec 27 04:15:10 EST 2000
"Eric G . Miller" wrote:
> On Thu, Dec 21, 2000 at 06:40:29PM +0700, Justin Hickey wrote:
> > So you have a choice for the source and install directories, but the
> > build directory is dependent on how the Makefile is written. All I'm
> > doing is rewriting the Makefile so the build directory is in the
> > usual place.
> > Are we understanding each other now? I was confused as to what you
> > were trying to point out. Sorry.
> Yes, the problem is the modules should be fully built in OBJ.$(ARCH)
> with "make" or "make all". But the modules/libes/etc, should not be
> "installed" unless "make install" is run.
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.
So, in our case, "make" not only needs to build the object files in
OBJ.$ARCH, but it also needs to build the executables in an etc/
directory somewhere and the rest of the directories and files needed to
run grass. Thus, after running "make", a user can run grass. However,
these directories should not be in system directories like
/usr/local/bin. Instead, they are currently under the SRCDIR directory.
Then to install the program for multiple users to access it, "make
install" copies these executables and other files to the proper
directories (eg /usr/local/grass5 and /usr/local/bin).
This leads me to reply to your "make install proposal for module
Makefiles" that you posted last week. I didn't have time to reply then
so I will now.
> On the subject of the GRASS gmake system being a little
> non-conforming, one thing I've wondered about is why wouldn't it be
> possible to rewrite Gmakefiles slightly so they include an "install"
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
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?
> I haven't really tried it, but I wonder if something like the
> following would work.
> OBJS = foo.o bar.o
> LIBES = $(GISLIB)
> PGM = foobar
> $(PGM): $(LIBES) foobar.h
> $(CC) -o $@ $(LDFLAGS) $(OBJS) $(LIBES) $(MATHLIB) $(XDRLIB)
> $(GISLIB): #
> install: $(PGM)
> $(INSTALL) $(PGM) $(BIN_MAIN)/$(PGM)
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)
# 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
$SRCDIR = /home/jhickey/grass
$BIN_MAIN = /home/jhickey/grass/dist.sgi/etc/bin/main/
$INST_DIR = /usr/local/grass5
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.
Perhaps if I gave examples of some of the variables from Makefile.in it
would clarify some things.
# Install directories - only accessed by make install
# Compile directories
# SRCDIR is where the source code is stored
# GISBASE is where the etc/, bin/, dev/, and other distribution files
# are stored at compile time
# GRASS_BIN is where grass5, gmake5, and gmakelinks5 are stored at
# compile time
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.
Please remember that this is only how I understand things based on my
experience with compiling open source software. Any comments are more
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey at hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev