[GRASS-dev] make install targets?

GRASS GIS GRASS GIS developer
1

(copied here from grass-user)

Related to below problem, would it be possible to add a
make install
target to all Makefiles? Then especially the GRASS Addons
installation would be greately simplified.

Markus

On Sun, Mar 30, 2008 at 12:57 PM, Gazz1982 <garynobles@yahoo.com> wrote:

That doesn't seem to work,

Here is my directory structure under grass

bin
bwidget
docs
driver
etc
fonts
include
lib
scripts

I copied the r.horizon2 folder into the bin directory and tried to make it
it returned the same error

I have superuser/root permissions

I'm sure when i do it once I will be able to do it again and again!

Thanks for your help

there isn't an imagery or raster folder should I make one in the grass
directory?

Nikos Alexandris wrote:
>
>
> On Sat, 2008-03-29 at 16:20 -0700, Gazz1982 wrote:
>> I have just been converted to Linux after struggling with cgywin!
>>
>> How do I install a new grass module, in this case I have the file
>> r.horizon2.tar.gz on my desktop and my $GISBASE is /usr/lib/grass
>
> (You might need to be superuser/root to do "make install" in the end)
>
> In general it must be something like:
> 1. copy "add-on" directory to /where/your/grass/source/is under the
> respective generic module category
>
> e.g. for i.pr it would be:
>
> cp -r i.pr /where/your/grass/source/is/imagery/
>
> 2. configure grass
>
> cd /where/your/source/is/
>
> ./configure #with your parameters
>
> 3. go to the "add-on" directory and "make it"
>
> e.g.
>
> cd /imagery/i.pr
>
> make
>
> 4. back to grass source directory
>
> make install
>
>
>>
>> I've done this before but I can't remember the commands and where
>> everything
>> should go
>>
>> Thanks
>
> Hope this helps (as it helped me once when somebody told me how make it)
>
> Cheers,
>
> Nikos

2

Markus Neteler wrote:

(copied here from grass-user)

Related to below problem, would it be possible to add a
make install
target to all Makefiles?

There are many cases which would require a custom install target (as
opposed to a generic target in e.g. Rules.make), as a generic target
wouldn't know which files it's supposed to be installing.

Realistically, this should wait for 6.4/7.x, when the build system
will get cleaned up to make it easier to build modules against an
installed version of GRASS.

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

3

On Sun, Mar 30, 2008 at 7:09 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

(copied here from grass-user)

Related to below problem, would it be possible to add a
make install
target to all Makefiles?

There are many cases which would require a custom install target (as
opposed to a generic target in e.g. Rules.make), as a generic target
wouldn't know which files it's supposed to be installing.

Realistically, this should wait for 6.4/7.x, when the build system
will get cleaned up to make it easier to build modules against an
installed version of GRASS.

I would still appreciate a generic "make install" - is that now feasible?

Markus

4

On Fri, Apr 10, 2009 at 3:03 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Sun, Mar 30, 2008 at 7:09 PM, Glynn Clements

...

Realistically, this should wait for 6.4/7.x, when the build system
will get cleaned up to make it easier to build modules against an
installed version of GRASS.

I would still appreciate a generic "make install" - is that now feasible?

quick and dirty patch attached...
It fails of course for multi-target cases such as r.mapcalc.

Markus

(attachments)

make_install.patch (1.05 KB)

5

On Fri, Apr 10, 2009 at 3:32 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Fri, Apr 10, 2009 at 3:03 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Sun, Mar 30, 2008 at 7:09 PM, Glynn Clements

...

Realistically, this should wait for 6.4/7.x, when the build system
will get cleaned up to make it easier to build modules against an
installed version of GRASS.

I would still appreciate a generic "make install" - is that now feasible?

I have added a
make install
target to 6.4.0svn and 6.5svn. No idea how to do it for 7.

It doesn't yet work for multi-targets such as r.mapcalc/r3.mapcalc but
it also doesn't interfere. So at least GRASS Addons can now be
installed easily with

make MODULE_TOPDIR=$HOME/grass64/
make MODULE_TOPDIR=$HOME/grass64/ install

Markus

6

Markus Neteler wrote:

>>> Realistically, this should wait for 6.4/7.x, when the build system
>>> will get cleaned up to make it easier to build modules against an
>>> installed version of GRASS.
>>
>> I would still appreciate a generic "make install" - is that now feasible?

I have added a
make install
target to 6.4.0svn and 6.5svn. No idea how to do it for 7.

It doesn't yet work for multi-targets such as r.mapcalc/r3.mapcalc but
it also doesn't interfere. So at least GRASS Addons can now be
installed easily with

make MODULE_TOPDIR=$HOME/grass64/
make MODULE_TOPDIR=$HOME/grass64/ install

Wouldn't it be simpler to just point ARCH_DISTDIR at the installed
version?

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

7

On Sun, Apr 12, 2009 at 3:32 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

>>> Realistically, this should wait for 6.4/7.x, when the build system
>>> will get cleaned up to make it easier to build modules against an
>>> installed version of GRASS.
>>
>> I would still appreciate a generic "make install" - is that now feasible?

I have added a
make install
target to 6.4.0svn and 6.5svn. No idea how to do it for 7.

It doesn't yet work for multi-targets such as r.mapcalc/r3.mapcalc but
it also doesn't interfere. So at least GRASS Addons can now be
installed easily with

make MODULE_TOPDIR=$HOME/grass64/
make MODULE_TOPDIR=$HOME/grass64/ install

Wouldn't it be simpler to just point ARCH_DISTDIR at the installed
version?

I don't know.

Note: The "make install" is also convenient if you want to update,
install and test only a single module in the main GRASS
source code (imagine you run in a shared production environment and
don't want to run "make install" globally but just for a specific module
to not touch the rest). A problem which I regularly have.
The submitted solution won't be brilliant (me & Makefiles... ) but works
for single modules. Improvements are welcome.

Markus

8

On Sun, Apr 12, 2009 at 3:32 PM, Glynn Clements<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

>>> Realistically, this should wait for 6.4/7.x, when the build system
>>> will get cleaned up to make it easier to build modules against an
>>> installed version of GRASS.
>>
>> I would still appreciate a generic "make install" - is that now feasible?

I have added a
make install
target to 6.4.0svn and 6.5svn. No idea how to do it for 7.

Any hope to get that fixed in GRASS 7?
I don't understand its Makefile system sufficiently.

It doesn't yet work for multi-targets such as r.mapcalc/r3.mapcalc but
it also doesn't interfere. So at least GRASS Addons can now be
installed easily with

make MODULE_TOPDIR=$HOME/grass64/
make MODULE_TOPDIR=$HOME/grass64/ install

Wouldn't it be simpler to just point ARCH_DISTDIR at the installed
version?

Still no clue how to do that.

Markus

9

Markus Neteler wrote:

>> >>> Realistically, this should wait for 6.4/7.x, when the build system
>> >>> will get cleaned up to make it easier to build modules against an
>> >>> installed version of GRASS.
>> >>
>> >> I would still appreciate a generic "make install" - is that now feasible?
>>
>> I have added a
>> make install
>> target to 6.4.0svn and 6.5svn. No idea how to do it for 7.

Any hope to get that fixed in GRASS 7?
I don't understand its Makefile system sufficiently.

The mechanism used in 6.5 can be copied almost verbatim to 7.0, but it
isn't particularly robust; there are a lot of special cases which
don't get accounted for.

One obvious improvement would be to replace the "install" targets in
the *.make files with more specific targets, e.g. "install_cmd",
"install_shlib", etc, and have the generic "install" target invoke
that. This would allow individual Makefiles to extend the install
target without having to clone the existing target.

Or the install targets could use double-colon rules; if multiple such
rules name the same target, making that target will execute the
commands for all of the rules (in no particular order). Normal
(single-colon) rules use the commands from the last rule. The main
downside with this approach is that individual Makefiles can only add
commands to the installation rule, not remove them.

Either way, any Makefile whose "default" rule isn't simply
"default: cmd", "default: lib", etc will need a custom "install"
target to install the additional files.

>> It doesn't yet work for multi-targets such as r.mapcalc/r3.mapcalc but
>> it also doesn't interfere. So at least GRASS Addons can now be
>> installed easily with
>>
>> make MODULE_TOPDIR=$HOME/grass64/
>> make MODULE_TOPDIR=$HOME/grass64/ install
>
> Wouldn't it be simpler to just point ARCH_DISTDIR at the installed
> version?

Still no clue how to do that.

  make ARCH_DISTDIR=/usr/local/grass-7.0svn

The main issue here is that it won't use the files in dist.<arch>, but
will re-create them, e.g. modules and libraries will be re-linked,
HTML files will be re-generated, etc.

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

10

On Sun, Jul 5, 2009 at 4:17 PM, Glynn Clements<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

>> >>> Realistically, this should wait for 6.4/7.x, when the build system
>> >>> will get cleaned up to make it easier to build modules against an
>> >>> installed version of GRASS.
>> >>
>> >> I would still appreciate a generic "make install" - is that now feasible?
>>
>> I have added a
>> make install
>> target to 6.4.0svn and 6.5svn. No idea how to do it for 7.

Any hope to get that fixed in GRASS 7?
I don't understand its Makefile system sufficiently.

The mechanism used in 6.5 can be copied almost verbatim to 7.0, but it
isn't particularly robust; there are a lot of special cases which
don't get accounted for.

Yes: it was moreover a proof of concept, sort of 80:20 solution.
In 7 it needs to be improved.

One obvious improvement would be to replace the "install" targets in
the *.make files with more specific targets, e.g. "install_cmd",
"install_shlib", etc, and have the generic "install" target invoke
that. This would allow individual Makefiles to extend the install
target without having to clone the existing target.

Or the install targets could use double-colon rules; if multiple such
rules name the same target, making that target will execute the
commands for all of the rules (in no particular order). Normal
(single-colon) rules use the commands from the last rule. The main
downside with this approach is that individual Makefiles can only add
commands to the installation rule, not remove them.

Either way, any Makefile whose "default" rule isn't simply
"default: cmd", "default: lib", etc will need a custom "install"
target to install the additional files.

I.e. the "multi" targets and maybe more.

>> It doesn't yet work for multi-targets such as r.mapcalc/r3.mapcalc but
>> it also doesn't interfere. So at least GRASS Addons can now be
>> installed easily with
>>
>> make MODULE_TOPDIR=$HOME/grass64/
>> make MODULE_TOPDIR=$HOME/grass64/ install
>
> Wouldn't it be simpler to just point ARCH_DISTDIR at the installed
> version?

Still no clue how to do that.

   make ARCH\_DISTDIR=/usr/local/grass\-7\.0svn

The main issue here is that it won't use the files in dist.<arch>, but
will re-create them, e.g. modules and libraries will be re-linked,
HTML files will be re-generated, etc.

You mean also for GRASS 6?

Markus

11

Markus Neteler wrote:

> Either way, any Makefile whose "default" rule isn't simply
> "default: cmd", "default: lib", etc will need a custom "install"
> target to install the additional files.

I.e. the "multi" targets and maybe more.

Makefiles which rely upon one of the *.make files to do most of the
work aren't really significant. The main issue is that many libraries
and modules have support files which get installed, usually under
$(ARCH_DISTDIR)/etc. Each such Makefile will need a custom install
target which installs those files from $(ARCH_DISTDIR) to $(INST_DIR).

The actual installation rule can be generalised to something like:

$(INST_DIR)/%: $(ARCH_DISTDIR)/%
  -test -d $(dir $@) || $(MKDIR) $(dir $@)
  if [ -x $< ] ; then $(INSTALL) $< $@ ; else $(INSTALL_DATA) $< $@ ; fi

But the module still needs to specify which files need to be installed
by the install target. This might be as simple as defining an
EXTRA_FILES variable, but it still has to be done in each Makefile.

>> > Wouldn't it be simpler to just point ARCH_DISTDIR at the installed
>> > version?
>>
>> Still no clue how to do that.
>
> make ARCH_DISTDIR=/usr/local/grass-7.0svn
>
> The main issue here is that it won't use the files in dist.<arch>, but
> will re-create them, e.g. modules and libraries will be re-linked,
> HTML files will be re-generated, etc.

You mean also for GRASS 6?

I don't know how well setting ARCH_DISTDIR it will work in GRASS 6.

I recently made a large number of changes to the Makefiles to separate
ARCH_DISTDIR, GISBASE, and RUN_GISBASE. The aim was to allow building
individual directories using an installed version, rather than having
to build the entire source tree, having GISBASE and MODULE_TOPDIR
pointing to e.g. /usr/local/grass-7.0.svn but with ARCH_DISTDIR
pointing to $srcdir/dist.$ARCH. But the reverse should also work.

Essentially, GISBASE is used to find existing files (libraries,
headers, etc) while ARCH_DISTDIR determines where new files are
created.

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