Re: dynamic dist?

[Ralf Wildenhues]

* Russ Allbery wrote on Sun, Apr 23, 2006 at 08:33:21PM CEST:
> Bob Proulx <[EMAIL PROTECTED]> writes:
> 
> > Hmm...  Well there is always:
> 
> >   test -d /usr/XPG4/bin && PATH=/usr/XPG4/bin:$PATH
> 
> > That might satisfy Mr. Solaris in this case.
> 
> (/usr/xpg4/bin in lowercase.)  It's been a while since I've built Solaris
> systems in anger, but as I recall, most of /usr/xpg4 is not in a required
> package.

And what's more, /usr/xpg4/bin/sed has a lower limit on the number of
commands allowed and/or script size.  This is important for Autoconf,
as config.status can create large sed scripts.  (I'm not fully done
with the analysis yet, but there may be a pending issue for Autoconf.)

Cheers,
Ralf

Re: dynamic dist?

[Russ Allbery]

Bob Proulx <[EMAIL PROTECTED]> writes:

> Hmm...  Well there is always:

>   test -d /usr/XPG4/bin && PATH=/usr/XPG4/bin:$PATH

> That might satisfy Mr. Solaris in this case.

(/usr/xpg4/bin in lowercase.)  It's been a while since I've built Solaris
systems in anger, but as I recall, most of /usr/xpg4 is not in a required
package.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: dynamic dist?

[Bob Proulx]

Hi Ralf,

Ralf Wildenhues wrote:
> Hi Bob,
> 
> * Bob Proulx wrote on Sun, Apr 23, 2006 at 05:35:23PM CEST:
> >
> > If you consider POSIX systems as being portable enough then using
> > the [:space:] character class should work pretty well.
> 
> Thanks to Mr. Solaris, no, I don't consider that portable enough.  ;-)

Hmm...  Well there is always:

  test -d /usr/XPG4/bin && PATH=/usr/XPG4/bin:$PATH

That might satisfy Mr. Solaris in this case.  It is a shame that he so
obstinately refuses to become more standard.  Sigh.

Bob

Re: dynamic dist?

[Ralf Wildenhues]

Hi Bob,

* Bob Proulx wrote on Sun, Apr 23, 2006 at 05:35:23PM CEST:
>
> If you consider POSIX systems as being portable enough then using
> the [:space:] character class should work pretty well.

Thanks to Mr. Solaris, no, I don't consider that portable enough.  ;-)

Cheers,
Ralf

Re: dynamic dist?

[Bob Proulx]

Ralf Wildenhues wrote:
> Tyler MacDonald writes:
> > OK, so I might need something more portable than cpio... but the
> >"\s.*" part does serve a purpose; the MANIFEST file format allows for a
> >description of the file after whitespace. I guess I could do "[ \t]" or
> >something else instead of the \s.
> 
> Ah, I didn't think of that.  You cannot use \t either, but using a literal
> TAB inside the brackets works portably AFAIK. 

If you consider POSIX systems as being portable enough then using
the [:space:] character class should work pretty well.

  s,[[:space:]].*,,

Bob

Re: AC_LIBOBJ(subdir/file) doesn't work with non-recursive automake

[Russ Allbery]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Russ Allbery wrote on Sun, Apr 23, 2006 at 04:05:11AM CEST:

>> AC_LIBOBJ([util/snprintf])

>> configure.ac:25: required file `./util/snprintf.c' not found

> I think it wasn't intended that AC_LIBOBJ ever be called with something
> other than a plain name (i.e., no directory components).  Not totally
> sure here, though.

With this patch, everything (Autoconf and Automake both) seems to work
fine, although of course without AC_CONFIG_LIBOBJ_DIR working, the
Autoconf macros that call AC_LIBOBJ internally don't do the right thing.

>> An even better solution would be for Automake to pay attention to
>> AC_CONFIG_LIBOBJ_DIR and look for AC_LIBOBJ files there.

> This is already fixed in CVS Automake.  It needs CVS Autoconf though.
> And the LIBOBJDIR feature is somewhat, erm, controversial.  Oh well.

I hope this does end up being supported, since it's the only way that I
see to make non-recursive builds work nicely with AC_LIBOBJ.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: AC_LIBOBJ(subdir/file) doesn't work with non-recursive automake

[Ralf Wildenhues]

Hi Russ,

* Russ Allbery wrote on Sun, Apr 23, 2006 at 04:05:11AM CEST:
> 
> AC_LIBOBJ([util/snprintf])

> configure.ac:25: required file `./util/snprintf.c' not found

I think it wasn't intended that AC_LIBOBJ ever be called with something
other than a plain name (i.e., no directory components).  Not totally
sure here, though.

> An even better solution would be for Automake to pay attention to
> AC_CONFIG_LIBOBJ_DIR and look for AC_LIBOBJ files there.

This is already fixed in CVS Automake.  It needs CVS Autoconf though.
And the LIBOBJDIR feature is somewhat, erm, controversial.  Oh well.

Cheers,
Ralf