[GRASS-dev] installed makefile cleanup

[Glynn Clements]

William Kyngesburye wrote:

> So, I came up with these "bases" for finding/creating files:
> 
> - INST_DIR - where make install target copies files to - can be  
> overridden for installing to external location (I worked on this  
> after my initial email).
> 
> - GRASS_HOME - source topdir (full path)

Actually, GRASS_HOME is an alias for DSTDIR (with 5.3, it used to be
possible to have separate source and destination directories, but I
don't think that works at present).

Ideally, this should be used as little as possible. Ideally, just as
the base for the dist.<arch> and bin.<arch> directories.

> - MODULE_TOPDIR - source topdir (usually relative path)

This has to be used for finding the Makefile fragments. Everything
else can be found via variables in Platform.make or Grass.make, but we
have to be able to find those files first.

> - ARCH_DISTDIR - where targets are built INTO before installation,  
> default based on GRASS_HOME
> 
> 
> and these use them (that are of interest to an external build/install):
> 
> - RUN_GISBASE -> ARCH_DISTDIR - but right now that's expanded by  
> configure

That should be changed; it should be set in the Makefiles from DSTDIR
(or, probably, WINDSTDIR).

> - RUN_GISRC -> ARCH_DISTDIR
> 
> - GISBASE -> ARCH_DISTDIR - usually reset to RUN_GISBASE (which is  
> just ARCH_DISTDIR anyways), but the main makefile uses it directly  
> for GRASS_PDFDIR

Having a variable named GISBASE in the Makefiles is rather confusing,
IMHO. I'd rather see ARCH_DISTDIR and INST_DIR, as it makes it clear
*which* GISBASE we're dealing with.

> So, as you said (it's making sense to me now), GISBASE somehow needs  
> its own base dir setting, defaulting to ARCH_DISTDIR, and which would  
> only need to be overridden by the INST_XTN build.
> 
> How about this: since GISBASE is really only for *running* GRASS, and  
> should only be set as needed (fix that GRASS_PDFDIR usage), don't use  
> it as a makefile var.

Agreed.

As for the rest of it, we're probably better off starting from basics.

The following might all be independently variable (with example
locations):

1. Where to find the GRASS source tree (/usr/local/src/grass)
2. Where to find the extension code which is being compiled (/usr/local/src/mygrassext)
3. Where to find output files (/usr/local/src/grass/<module path>/OBJ.<arch>)
4. Where to find "part-installed" files (/usr/local/src/grass/dist.<arch>)
5. Where to find the installed version of GRASS (/usr/local/grass6.3)
6. Where to put output files (/usr/local/src/grass/<module path>/OBJ.<arch>)
7. Where to put "part-installed" files (/usr/local/src/grass/dist.<arch>)
8. Where to install everything (/usr/local/grass6.3)
9. Where to find the Makefile fragments.

AFAICT, there are three main cases:

A. Compiling GRASS from scratch.
B. Compiling additional modules on a system where a compiled GRASS is already installed.
C. Compiling extensions on a system where a compiled GRASS is already installed.

For A, 2 and 5 don't apply.
For B, 1 and 2 don't apply.
For C, 1 doesn't apply.

In each case, the build directory may or may not reside within the
same directory as the source tree.

In all cases, 3 and 4 will share a common base directory, as will 6
and 7.

Also, A will use 4 where B and C use 5.

Where possible, 4 is preferable to 1, i.e. if a file is part-installed
as part of the build process, the part-installed file should be used
instead of the original (e.g. GRASS headers are obtained from
dist.<arch>/include, not from the source tree).

3 should be avoided at all costs. Grass.make[.in] has:

  FMODE_OBJ = $(MODULE_TOPDIR)/lib/gis/$(OBJDIR)/fmode.o

This means that, on Windows, you cannot compile additional modules
using an installed version of GRASS, as fmode.o isn't present in the
installed version.

Any file which needs to be used by libraries or modules other than the
one which creates it should go into 7 and be referenced from 4.

9 (MODULE_TOPDIR) may be an alias for either 1 or 5, but it has to
have a fall-back hard-coded into each Makefile, and that fall-back has
to be a relative path to 1.

I'm not entirely sure whether using 9 should be preferred or avoided. 

I'm leaning towards the view that it should be preferred, so that 1 is
eliminated. IOW, if you want to find something in the GRASS source
tree, use $(MODULE_TOPDIR). That way, you only have to set one
variable to build against an installed version.

Note that extensions shouldn't set MODULE_TOPDIR, as this needs to
refer to the top of the GRASS source (so that
$(MODULE_TOPDIR)/include/Make/*.make can be found), and extensions
won't know where this is.

-- 
Glynn Clements <glynn at gclements.plus.com>