The changes that Dirk is suggesting would help for several packages I
maintain, particularly rpy.
-G
On 6/8/08 1:05 PM, "Dirk Eddelbuettel" <[EMAIL PROTECTED]> wrote:
>
>
> Brian,
>
> On 6 June 2008 at 07:33, Dirk Eddelbuettel wrote:
> |
> | On 6 June 2008 at 13:13, Prof Brian Ripley wrote:
> | | > On 6 June 2008 at 11:34, Prof Brian Ripley wrote:
> | | > | Isn't this what Type: Frontend is for? That gives you complete
> control
> | | > | and would seem appropriate for both of your examples.
> | | >
> | | > Interesting. But the R Extensions manual says
> | | >
> | | > 1.10.1 Frontend
> | | > ---------------
> | | >
> | | > This is a rather general mechanism, designed for adding new front-ends
> | | > such as the *gnomeGUI* package. If a `configure' file is found in the
> | | > top-level directory of the package it is executed, and then if a
> | | > `Makefile' is found (often generated by `configure'), `make' is
> called.
> | | > If `R CMD INSTALL --clean' is used `make clean' is called. No other
> | | > action is taken.
> | | >
> | | > I am talking about the need for 'other action' such as 'make install',
> say.
> | | >
> | | > Are you suggesting I shoehorn what I want done into the main 'make'
> target ?
> | |
> | | Yes. I don't see it as 'shoehorn' -- it is the install step.
> |
> | I have to think about this. I was envisioning a degree of freedom between
> | 'make' and 'make install'. I may need some optionality here.
> |
> | Anyway -- thanks for the suggestions. It is indeed very close to what I had
> | asked for.
>
> Thanks again for the gnomeGui suggestion. I looked at it and it comes close
> but offer no cigar yet. So looking at the code in $R_HOME/bin/INSTALL:
>
> if test "$Type" = "Frontend" ; then
> message "Installing *Frontend* package '${pkg_name}' ..."
> if ${preclean}; then
> ${MAKE} clean
> fi
> if ${use_configure} && test -x ./configure ; then
> eval ${configure_vars} ./configure ${configure_args}
> if test ${?} -ne 0; then
> error "configuration failed for package '${pkg_name}'"
> do_exit_on_error
> fi
> fi
> if test -f ./Makefile ; then
> ${MAKE}
> if test ${?} -ne 0; then
> error "make failed for package '${pkg_name}'"
> do_exit_on_error
> fi
> if ${clean}; then
> ${MAKE} clean
> fi
> return
> fi
> return
> fi
>
> it is clear that the 'make install' step Jeff and I have asked about is not
> there.
>
> Seeing how behaviour in the 'Frontend' case can be conditioned on flags like
> --preclean, would there be objections to a patch implementing a new option,
> say, --frontendinstall (or something similar that is shorter and more
> expressive) that would, if set, call '${MAKE} install' before the 'make
> clean' step ?
>
> Better still, and in order to make things more autoMAGIC so that we can use
> features like update.packages(), could the 'make install' case be conditional
> on a) the 'Type = Frontend' choice in DESCRIPTION _and_ b) a top-level script
> frontend-install in the package? So instead of an user the user had to
> choose, could we just run this for her a la
>
> if test -f ./frontend-install; then
> ./frontend-install
> ## alternatively, run ${MAKE} install
> if test ${?} -ne 0; then
> error "make install failed for package '${pkg_name}'"
> do_exit_on_error
> fi
>
> Thirdly, I don't really see why we can't just run 'make install'
> unconditionally. That may need a minor patch to gnomeGUI to move the
> (somewhat non-standard) 'install' target out of the 'make all' dependencies.
>
> I'd be happy to work on a complete patch that also updates the discussion in
> the R Extensions manual, R Admin manual and the INSTALL help text, plus
> whereever else INSTALL is documented.
>
> Regards, Dirk
>
> --
> Three out of two people have difficulties with fractions.
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
