R-Project build system: DESTDIR support

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

R-Project build system: DESTDIR support

Claudio Fontana-2
Hello,

I am writing you about the GNU R-Project,
as part of by effort to help GNU projects provide a better, more
consistent build system.

Currently, your project does not support the DESTDIR variable in
generated Makefiles (marked as optional in the GNU coding policies, make and
automake manual).

In my opinion, DESTDIR support can be very helpful for the user, the
distribution-specific packagers and third-party programs, because it
offers a consistent and portable way to perform staged installations.

In each case, please contact me at this address <[hidden email]>
to provide your feedback about this issue _in any case_, should you
want to support DESTDIR or not.

I am ready to offer you information, help and support.

Thank you for your help in making GNU projects build systems better.

Claudio Fontana

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R-Project build system: DESTDIR support

Dirk Eddelbuettel

Hi Claudio,

On 25 February 2006 at 03:11, Claudio Fontana wrote:
| Hello,
|
| I am writing you about the GNU R-Project,
| as part of by effort to help GNU projects provide a better, more
| consistent build system.
|
| Currently, your project does not support the DESTDIR variable in
| generated Makefiles (marked as optional in the GNU coding policies, make and
| automake manual).
|
| In my opinion, DESTDIR support can be very helpful for the user, the
| distribution-specific packagers and third-party programs, because it
| offers a consistent and portable way to perform staged installations.

I'm confused. We've been maintaining R in Debian quite merrily even with the
exisiting standards. To the best of my knowledge things seem to work without
DESTDIR.

In a nutshell, what we do -- and this is, or at least used to be, pretty
canonical across GNU-style packages and has been in effect for probably a
dozen years.  Now, I may miss something newer happening elsewhere...

The key is that configure details the _final_ location on the installed
system, whereas 'make install' pivots off to a subdirectory in the archive of
the currently built package is 'installed' before being tarred:

        ./configure --prefix=/usr \
                    --with-system-bzlib \
[...]
                    --build $(buildarch)

[...]

        $(MAKE) CFLAGS="$(compilerflags)" \
                        CXXFLAGS="$(compilerflags)" \
                        FFLAGS="$(compilerflags)" \
                        CC=${compiler} \
                        CXX=${cxxcompiler} \
                        ${fortrancompiler} \
                        R

[...]

        $(MAKE) prefix=$(debtmp)/usr \
                mandir=$(debtmp)/usr/share/man \
                rsharedir=$(debtmp)/usr/share/R/share \
                rincludedir=$(debtmp)/usr/share/R/include \
                rdocdir=$(debtmp)/usr/share/R/doc \
                install

So could you detail how using DESTDIR makes this (or, for that matter,
another) use case any easier or better?
 
| In each case, please contact me at this address <[hidden email]>
| to provide your feedback about this issue _in any case_, should you
| want to support DESTDIR or not.
|
| I am ready to offer you information, help and support.

You may want to talk to Kurt Hornik who covers the autoconf et al build
process for R.  Whenever I had little gripes or needs, he reflected these
and typically with much better solutions than I could have proposed :)
 
| Thank you for your help in making GNU projects build systems better.

Thanks for this initiative. It could indeed makes things better

Cheers, Dirk


--
Hell, there are no rules here - we're trying to accomplish something.
                                                  -- Thomas A. Edison

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R-Project build system: DESTDIR support

Claudio Fontana

Hello Dirk,
thanks for your answer.

--- Dirk Eddelbuettel <[hidden email]> wrote:

>
> Hi Claudio,
>
> On 25 February 2006 at 03:11, Claudio Fontana wrote:
> | Hello,
> |
> | I am writing you about the GNU R-Project,
> | as part of by effort to help GNU projects provide
> a better, more
> | consistent build system.
> |
> | Currently, your project does not support the
> DESTDIR variable in
> | generated Makefiles (marked as optional in the GNU
> coding policies, make and
> | automake manual).
> |
> | In my opinion, DESTDIR support can be very helpful
> for the user, the
> | distribution-specific packagers and third-party
> programs, because it
> | offers a consistent and portable way to perform
> staged installations.
>
> I'm confused. We've been maintaining R in Debian
> quite merrily even with the
> exisiting standards. To the best of my knowledge
> things seem to work without
> DESTDIR.

No need to be confused. DESTDIR is not required to be
able to maintain your project in Debian or in other
GNU/Linux distributions or other Unix-likes.

> In a nutshell, what we do -- and this is, or at
> least used to be, pretty
> canonical across GNU-style packages and has been in
> effect for probably a
> dozen years.  Now, I may miss something newer
> happening elsewhere...

AFAIK widespread DESTDIR use has begun with the
support in Automake, about 6-7 years ago.
DESTDIR dates back to the older INSTALL_ROOT, which is
still in use in the tcl community.

> The key is that configure details the _final_
> location on the installed
> system, whereas 'make install' pivots off to a
> subdirectory in the archive of
> the currently built package is 'installed' before
> being tarred [cut]
>
> So could you detail how using DESTDIR makes this
> (or, for that matter,
> another) use case any easier or better?

(
 I got your example screwed up by this mail service
 and was difficult to read - care to send a possibly
 more verbose version as attachment?
)

What you describe is conceptually very similar to
DESTDIR, if I understand you correctly.

A difference is that DESTDIR is written in the
Makefile.in, for each installation or uninstallation
rule, without altering the primaries. [...]

It only applies to the install/uninstall phase, so
hard-coded paths, and other location-dependant stuff
determined at build time remains valid for the final
destination.

DESTDIR is widely known and portable, and users and
programs can rely on it for running commands on the
to-be-installed files for different goals.

simple usage:
./configure --prefix=/my/final/prefix
make
make install DESTDIR=/staged/directory

simple rule example:
$(INSTALL_DATA) $(srcdir)/file.dat
$(pkgdatadir)/file.dat

becomes

$(INSTALL_DATA) $(srcdir)/file.dat
$(DESTDIR)$(pkgdatadir)/file.dat

Automake generates DESTDIR support automatically (with
some caution required in custom installation hooks).

Probably many sources can provide you more information
about DESTDIR that I can.

More info is available in the GNU coding standards
(Makefile conventions), GNU make and GNU automake
manuals, and it is probably topical in the autotools
lists too. Google gives me some good hits for DESTDIR
too.

> | In each case, please contact me at this address
> <[hidden email]>
> | to provide your feedback about this issue _in any
> case_, should you
> | want to support DESTDIR or not.
> |
> | I am ready to offer you information, help and
> support.
>
> You may want to talk to Kurt Hornik who covers the
> autoconf et al build
> process for R.  Whenever I had little gripes or
> needs, he reflected these
> and typically with much better solutions than I
> could have proposed :)

Great, maybe you can forward our conversation?
 
> | Thank you for your help in making GNU projects
> build systems better.
>
> Thanks for this initiative. It could indeed makes
> things better

I hope so, as I am putting a lot of effort in this.

> Cheers, Dirk

Best,

CLaudio

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R-Project build system: DESTDIR support

Hin-Tak Leung-2
In reply to this post by Dirk Eddelbuettel
Dirk Eddelbuettel wrote:
> Hi Claudio,
>
> On 25 February 2006 at 03:11, Claudio Fontana wrote:
<snipped>
> | Currently, your project does not support the DESTDIR variable in
> | generated Makefiles (marked as optional in the GNU coding policies, make and
> | automake manual).
<snipped>
> I'm confused. We've been maintaining R in Debian quite merrily even with the
> exisiting standards. To the best of my knowledge things seem to work without
> DESTDIR.
<snipped>

You are both right - R currently does not use DESDIR, and also R seems
to work without it. What happens is that R is *almost* completely
re-locatable based on one environment variable R_HOME . There is one
wrapper script (/usr/bin/R) which contains the location of R_HOME,
and it is "massaged" with the intended R_HOME location just before
"make install". The "make install" process essentially just copy
all the files into the intended R_HOME, edit the wrapper script
with the location of R_HOME and copy it also.

Change to DESTDIR should be quite simple. I think it is mostly one
line change in R/Makeconf.in,
where
        rhome = ${libdir}/R
to
        rhome = ${DESTDIR}/${libdir}/R
and maybe one or two other places, concerning that wrapper script.
(some volunteers?)

HTL

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R-Project build system: DESTDIR support

Hin-Tak Leung-2
In reply to this post by Claudio Fontana-2
Claudio Fontana wrote:
> Hello,
>
> --- Hin-Tak Leung <[hidden email]>
<snipped>

>>Change to DESTDIR should be quite simple. I think it
>>is mostly one
>>line change in R/Makeconf.in,
>>where
>>        rhome = ${libdir}/R
>>to
>>        rhome = ${DESTDIR}/${libdir}/R
>>and maybe one or two other places, concerning that
>>wrapper script.
>
>
> Please DON'T. If I understood your idea correctly,
> this is not the meaning of DESTDIR,
> and placing DESTDIR there is harmful since its meaning
> is overloaded. The staged installation does _not_ need
> to be functional. Its hard coded paths must refer to
> the _final destination_ which is determined by prefix
> only.
<snipped>

> Then try this (replace user with your user name):
>
> $ tar -zxvf bc-1.06.tar.gz
> $ cd bc-1.06
> $ ./configure --prefix=/home/user/tmp
> $ make
> $ make install DESTDIR=/home/user/install-destdir
> $ ls /home/user/tmp
> ls: /home/user/tmp: No such file or directory
> $ find /home/user/install-destdir
> [study the output of this command]

I don't think you understand me correctly.
Doing the insertion as I wrote, (Makeconf.in is
included by R's top-level Makefile as far as I understand it),
would make "make install DESTDIR=/someotherroot/" work.
You probably mean this construction:

DESTDIR ?=${libdir}/R
rhome = ${DESTDIR}

instead. Either way, please study what Makeconf.in does.

HTL

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R-Project build system: DESTDIR support

Claudio Fontana

--- Hin-Tak Leung <[hidden email]>
wrote:

> Claudio Fontana wrote:
> > Hello,
> >
> > --- Hin-Tak Leung <[hidden email]>
> <snipped>
> >>Change to DESTDIR should be quite simple. I think
> it
> >>is mostly one
> >>line change in R/Makeconf.in,
> >>where
> >>        rhome = ${libdir}/R
> >>to
> >>        rhome = ${DESTDIR}/${libdir}/R
> >>and maybe one or two other places, concerning that
> >>wrapper script.
> >
> >
> > Please DON'T. If I understood your idea correctly,
> > this is not the meaning of DESTDIR,
> > and placing DESTDIR there is harmful since its
> meaning
> > is overloaded. The staged installation does _not_
> need
> > to be functional. Its hard coded paths must refer
> to
> > the _final destination_ which is determined by
> prefix
> > only.
> <snipped>
> > Then try this (replace user with your user name):
> >
> > $ tar -zxvf bc-1.06.tar.gz
> > $ cd bc-1.06
> > $ ./configure --prefix=/home/user/tmp
> > $ make
> > $ make install DESTDIR=/home/user/install-destdir
> > $ ls /home/user/tmp
> > ls: /home/user/tmp: No such file or directory
> > $ find /home/user/install-destdir
> > [study the output of this command]
>
> I don't think you understand me correctly.

I am now pretty sure I did.

> Doing the insertion as I wrote, (Makeconf.in is
> included by R's top-level Makefile as far as I
> understand it),
> would make "make install DESTDIR=/someotherroot/"
> work.

It works, but not in the way its intended.

> Either way, please study what Makeconf.in
> does.
>
> HTL

I did, and does not seem ok.
Look:

- make the change in Makeconf.in:
  rhome = $(DESTDIR)${libdir}/R

now I do:

$ ./configure --prefix=/home/claudio/tmp
$ make
$ make install DESTDIR=/home/claudio/install-destdir

$ find /home/claudio/tmp
/home/claudio/tmp
/home/claudio/tmp/man
/home/claudio/tmp/man/man1
/home/claudio/tmp/man/man1/R.1
/home/claudio/tmp/bin
/home/claudio/tmp/bin/R

[not ok, should return: /home/claudio/tmp: No such
file or directory. ]

Now for the more important thing:

$ cat /home/claudio/tmp/bin/R
#!/bin/sh
# Shell wrapper for R executable.

R_HOME_DIR=/home/claudio/install-destdir/home/claudio/tmp/lib/R
if test -n "${R_HOME}" && \
   test "${R_HOME}" != "${R_HOME_DIR}"; then
  echo "WARNING: ignoring environment value of R_HOME"
fi
R_HOME="${R_HOME_DIR}"
export R_HOME
R_SHARE_DIR=/home/claudio/install-destdir/home/claudio/tmp/lib/R/share
export R_SHARE_DIR
R_INCLUDE_DIR=/home/claudio/install-destdir/home/claudio/tmp/lib/R/include
export R_INCLUDE_DIR
R_DOC_DIR=/home/claudio/install-destdir/home/claudio/tmp/lib/R/doc
export R_DOC_DIR

 [
  not ok: the software itself must be DESTDIR unaware.
  Those paths should read for example:
  R_SHARE_DIR=/home/claudio/tmp/lib/R/share

  The binaries, the datafiles, and the content of
  everything else that gets installed should be
  indistinguishable from a non-DESTDIR installation.
  Moving the staged installation to the
  final place should be (more or less[...]) a matter
  of one mv command.
 ]

Do you see the difference in meaning between your
concept and the DESTDIR concept?

CLaudio

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel