[Top][All Lists]

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

Re: arg-nonnull.h & warn-on-use.h in build-aux

From: Sam Steingold
Subject: Re: arg-nonnull.h & warn-on-use.h in build-aux
Date: Tue, 23 Feb 2010 17:56:33 -0500

On 2/23/10, Eric Blake <address@hidden> wrote:
> According to Sam Steingold on 2/23/2010 3:06 PM:
> >>  > I updated gnulib in clisp and gnulib-tool installed arg-nonnull.h &
>  >>  > warn-on-use.h in src/build-aux.
>  >>  > why aren't these files in the usual place (src/gllib), together with 
> all
>  >>  > the other headers?
>  >>
>  >> Because the versions in src/build-aux are templates, which get further
>  >>  modified by a sed script during make, such that you end up using the
>  >>  modified contents as the inline portion merged with *.in.h header
>  >>  templates to form replacement headers in build/gllib.
>  >
>  > I am not sure I see the fundamental difference.
> For warn-on-use.h, I was just following the precedence set by Bruno during
>  arg-nonnull.h.  Beyond that, this is more of Bruno's question why he
>  picked build-aux rather than gllib for the templates to live in,
>  particularly given that our *.in.h templates live in gllib.

Bruno! Bruno!

>  > I want to enable my users to build clisp modules against an existing
>  > system-wide clisp installation (and install the user-built modules in
>  > their home directory), similar to the way cpan works for perl.
>  >
>  > since the configure files refer to some build-aux files, I have to
>  > install those files when I install clisp.
> I'm not much of a fan of installing from build-aux; so it seems like you
>  have a use case that deserves some refactoring on the gnulib side of
>  things.  But at this point, I'm hoping Bruno can step in and comment.

Bruno! Bruno!

>  > I want to be able to add build_aux=.... to the $(MAKE) invocation
>  > so that the file arg-nonnull.h & warn-on-use.h are found in the right 
> place.
> In other words, the factorization allows you to override just $(build_aux)
>  as needed.  But it depends on us being able to find a way to populate
>  $(build_aux) with the correct default in the absence of your module setup,
>  and is also only relevant if we can't come up with some better upstream
>  layout in the first place.

All you need to do is tell automake to add
to Makefile.in and you are perfectly backwards compatible.

Sam Steingold <http://sds.podval.org>

reply via email to

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