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

[Justin: I put this back on list to get others' feedback.]

On Tue, Dec 19, 2000 at 03:00:39PM +0700, Justin Hickey wrote:

I set the clean targets (except for savebinclean) to follow the GNU
standard clean targets. See the Makefile for the link to the GNU web
page I used as a reference. However, it is possible that I interpreted
those targets incorrectly. Please let me know if you have another
interpretation.

I finally was able to read the document referenced in the Makefile.in.
I read it to say "clean, distclean, etc." do *not* touch any installed
files. It only seems to refer to files in the in the "current" build
directory. The only place I see reference about removing installed
files is with the "uninstall" target (and then it needs a list to go
from). I think we could easily have an uninstall target, since a
recursive delete of $(GISBASE), and the removal of $(PREFIX)/grass5 and
friends would be the only targets. If there was a decent way to
generate a list of install files, using that would probably be
preferrable.

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" target? 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)
-------------------------------------------------

I see a problem with the dependency check on $(GISLIB), but other than
that, am I missing something? Is there a problem with the way the
next_head stuff works, or is it in gmake itself?

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

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

Hi Eric

"Eric G . Miller" wrote:

[Justin: I put this back on list to get others' feedback.]

On Tue, Dec 19, 2000 at 03:00:39PM +0700, Justin Hickey wrote:
> I set the clean targets (except for savebinclean) to follow the GNU
> standard clean targets. See the Makefile for the link to the GNU web
> page I used as a reference. However, it is possible that I
> interpreted those targets incorrectly. Please let me know if you
> have another interpretation.

I finally was able to read the document referenced in the Makefile.in.
I read it to say "clean, distclean, etc." do *not* touch any installed
files. It only seems to refer to files in the in the "current" build
directory. The only place I see reference about removing installed
files is with the "uninstall" target (and then it needs a list to go
from). I think we could easily have an uninstall target, since a
recursive delete of $(GISBASE), and the removal of $(PREFIX)/grass5
and friends would be the only targets. If there was a decent way to
generate a list of install files, using that would probably be
preferrable.

The problem is not that the clean directories touch the installed files.
The problem is that the installation directories and the build
directories are under the *same physical directory*. I am now in the
testing phase of the proposal I made earlier for a new Makefile that
will separate the build and installation directories. Now that the
directories are separate, the clean targets do not touch the
installation directory and there is an uninstall target to remove the
installation files. Hopefully I'll be able to check in the new system
tomorrow for people to test.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

On Thu, Dec 21, 2000 at 03:51:08PM +0700, Justin Hickey wrote:

The problem is not that the clean directories touch the installed files.
The problem is that the installation directories and the build
directories are under the *same physical directory*. I am now in the

That's your choice. I have grass sources under /usr/local/src/grass,
but the binaries are in /usr/local/grass5. So they are not in the same
directory tree (well, /usr/local ;).

testing phase of the proposal I made earlier for a new Makefile that
will separate the build and installation directories. Now that the
directories are separate, the clean targets do not touch the
installation directory and there is an uninstall target to remove the
installation files. Hopefully I'll be able to check in the new system
tomorrow for people to test.

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

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

Hi Eric

"Eric G . Miller" wrote:

That's your choice. I have grass sources under /usr/local/src/grass,
but the binaries are in /usr/local/grass5. So they are not in the
same directory tree (well, /usr/local ;).

Ahh, now I know where the confusion is. The build directories are not
necessarily the same as the source directories. Lets see if I can
clarify things. The following is my understanding of the GNU set of
directories. The source directories is where the source is stored. The
build directories are where the files that are compiled (libraries and
executables) are stored at the time they are compiled. The installation
directories is where the executables (mainly) are copied to after they
are compiled. However, in typical GNU installations, the build
directories are usually under the source directories.

Now in Grass, we currently have the opposite. The build directories are
under the installation directories. That is, when grass is compiled the
executables are compiled directly to the installation directories. We do
not have a step in the compilation that copies the files from the build
directories to the installation directories. Thus, if we want to clean
the build directories, we must clean the installation directories.

My proposal switches the Makefile to the GNU method of doing things
where the build directories are under the source directory. Then "make"
will build the executables in the build directories which will be stored
under the source directory, in your case /usr/local/src/grass/. Then
"make install" will copy the files to the installation directories, in
your case /usr/local/grass5/. And "make clean" will remove the
executables and libraries from the build directories under
/usr/local/src/grass/. Finally, "make uninstall" will remove the
executables from the installation directory /usr/local/grass5/

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.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Justin,

I started on this a while ago, but Real Life (tm) has
left me with less than no free time available. Here's
how far I got (only works for now on Linux, needs some
configure.in work for other platforms, etc.) Actually,
I think I started on some of the executables, but I'd
have to check my source tree. Let me know what you
think of it.

Justin Hickey wrote:

My proposal switches the Makefile to the GNU method of doing things
where the build directories are under the source directory. Then "make"
will build the executables in the build directories which will be stored
under the source directory, in your case /usr/local/src/grass/. Then
"make install" will copy the files to the installation directories, in
your case /usr/local/grass5/. And "make clean" will remove the
executables and libraries from the build directories under
/usr/local/src/grass/. Finally, "make uninstall" will remove the
executables from the installation directory /usr/local/grass5/

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.

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534 Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR 4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122 Bowie, MD 20716 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\ / o=\ /"""---===/
         / \_/ \__/ ---===/
         | //\ || /""TT""/ //\ || ||""\
         | // \ || || // \ || ||__/
         | //--==\ |L--/ || //--==\ || || "=,
          \ ---===/
           \____---===/

(attachments)

grass.remake.tgz (14.6 KB)
grass.reMake (1.13 KB)

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. So, I think we are
understanding each other...

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

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

Hi Eric

"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"
target?

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?

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)

$(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

$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
PREFIX= /usr/local
prefix= /usr/local
exec_prefix= /usr/local
BINDIR= /usr/local/bin
INST_DIR= /usr/local/grass5

# Compile directories

# SRCDIR is where the source code is stored
SRCDIR= /home/jhickey/grass

# GISBASE is where the etc/, bin/, dev/, and other distribution files
# are stored at compile time
GISBASE= /home/jhickey/grass/dist.sgi

# GRASS_BIN is where grass5, gmake5, and gmakelinks5 are stored at
# compile time
GRASS_BIN= /home/jhickey/grass/bin.sgi

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

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

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@jps.net>

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

Justin,

   The new Makefile system seems to work nicely. Just wanted to give
you kudos for a job well done.

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

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

Hi Eric

"Eric G . Miller" wrote:

Justin,

   The new Makefile system seems to work nicely. Just wanted to give
you kudos for a job well done.

Thanks. I appreciate it.

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.

Yep you're right. It should be INSTALL. I'll change it. Thanks for the
tip.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'