bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: uninstalling relocation wrappers


From: Ben Pfaff
Subject: Re: uninstalling relocation wrappers
Date: Mon, 14 Jun 2010 09:36:17 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Bruno Haible <address@hidden> writes:

>> +uninstall-hook: uninstall-relocwrapper
>> +uninstall-relocwrapper:
>> +if RELOCATABLE_VIA_LD
>> +    @:
>> +else
>> +    if test $(RELOCATABLE) = yes; then \
>> +        case '$(EXEEXT)' in \
>> +            .bin*) ;; \
>> +            *) $(MAKE) uninstall EXEEXT=.bin$(EXEEXT) ;; \
>> +        esac; \
>> +    fi
>> +endif
>
> Hmm, I don't like targets that contain empty commands in the default
> case (when no relocatability is requested): it looks like bloat. I'm
> adding a conditional 'RELOCATABLE_VIA_WRAPPER' that should allow you
> to simplify this code.

OK, thanks.

> Btw, in gnulib contributions, please indent shell statements by 2 spaces,
> not 4 spaces.

OK, I updated my local copy.

>> --- a/doc/relocatable-maint.texi
>> +++ b/doc/relocatable-maint.texi
>> @@ -145,6 +145,14 @@ foo_LDFLAGS = `$(RELOCATABLE_LDFLAGS) $(bindir)`
>>  endif
>>  @end example
>>  
>> +Also, only in the @file{Makefile.am} at the top level of your source
>> +tree, add the following.  Replace @samp{build-aux}, if necessary, by
>> +the directory where @file{gnulib-tool} places auxiliary build tools:
>> +
>> address@hidden
>> +include build-aux/relocwrapper.am
>> address@hidden example
>
> I would prefer to avoid Makefile.am fragments and 'include' statements.
> The reason is that here we start to get dependencies on the file layout
> of the package.
>
> The automake documentation says:
>
>    There are two forms of `include':
>
>   `include $(srcdir)/file'
>        Include a fragment that is found relative to the current source
>        directory.
>
>   `include $(top_srcdir)/file'
>        Include a fragment that is found relative to the top source
>        directory.
>
> and your example is not one of these. Then, if the package's configure.ac
> invokes AC_CONFIG_AUX_DIR, the string 'build-aux/' needs to be replaced
> accordingly. This does not make it easier for the package maintainer.

I've changed this to 
        include $(top_srcdir)/build-aux/relocrwapper.am
in my loacl copy.

> Instead, I would better see an AC_SUBSTed and AM_SUBST_NOTMAKEd variable
> that expands to
>
>    uninstall-hook:
>
> if RELOCATABLE_VIA_WRAPPER is false, and to
>
>    uninstall-hook: uninstall-relocwrapper
>    uninstall-relocwrapper: ; case '$(EXEEXT)' in .bin*) ;; *) $(MAKE) 
> $(AM_MAKEFLAGS) uninstall EXEEXT=.bin$(EXEEXT) ;; esac
>
> if RELOCATABLE_VIA_WRAPPER is true. Unfortunately, I don't see how to
> reduce this to a single line; this would make it unnecessary to rely on
> AM_SUBST_NOTMAKE - but how?
>
> Such a variable could be used in any Makefile.am, without thinking about
> how to access 'build-aux/'.

I agree that this is a nicer approach, but it does not work.  If
Automake cannot see that uninstall-hook is in use when it
processes Makefile.am, then it does not call it.  So this
approach will only work in `Makefile.am's that already have an
uninstall-hook.

> Btw, make recursions in automake generated Makefile.ins use
>   $(MAKE) $(AM_MAKEFLAGS)
> not plain
>   $(MAKE)

Thanks, I've fixed that in my local copy.

Here is another approach that I had not thought of before.
What if we added the following to
modules/relocatable-prog-wrapper:

Makefile.am:
if RELOCATABLE_VIA_WRAPPER
uninstall-hook: uninstall-relocwrapper
uninstall-relocwrapper:
        if test $(RELOCATABLE) = yes; then \
          case '$(EXEEXT)' in \
            .bin*) ;; \
            *) cd $(top_builddir) && \
               $(MAKE) $(AM_MAKEFLAGS) EXEEXT=.bin$(EXEEXT) \
                       AM_MAKEFLAGS='$(AM_MAKEFLAGS) EXEEXT=.bin$(EXEEXT)' \
                       uninstall ;; \
          esac; \
        fi
.PHONY: uninstall-relocwrapper
endif

I haven't tested it yet, and I'm a little worried about whether
this is unwarranted abuse of AM_MAKEFLAGS.
-- 
Ben Pfaff 
http://benpfaff.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]