On 13-12-05 06:25 PM, Stefano Lattarini wrote:
>> For good or for bad, there
>> > are enough developers that think of the autotools as magic black boxes
>> > that they are unwilling to use any version not shipped by their distro.
>> >
> I'm not willing to go to great lengths to support such attitud
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13-12-05 05:49 PM, Eric Blake wrote:
> AM_INIT_AUTOMAKE([1.11.1 gnits ...]m4_ifdef([1.13-witness], [
> serial-tests])
I ended up working around it like this:
https://github.com/behdad/harfbuzz/commit/2646aec1e67cd6e09f5f7859c9d5898917acc2d5
- --
On 13-12-05 05:28 PM, Stefano Lattarini wrote:
> Why not? 1.13 is almost one year old now...
Why not? Because I don't require any feature new in 1.13, yet it breaks my
package. Also because it's in no long-term-support distro like Ubuntu 12.04.
I personally installed 1.13 and released a tarball
FWIW, the serial-tests is useless since it makes automake < 1.13 to fail. :(
On 13-12-04 08:37 PM, Behdad Esfahbod wrote:
> Hi,
>
> Please advise how one is supposed to port their pre-1.13 test suite's
> TESTS_ENVIRONMENT to 1.13. Currently, in fontconfig and harfbuzz at lea
Hi,
Please advise how one is supposed to port their pre-1.13 test suite's
TESTS_ENVIRONMENT to 1.13. Currently, in fontconfig and harfbuzz at least, we
cannot find a solution that works both with 1.11 and 1.13, and we cannot
require 1.13.
Example change that is not acceptable:
https://github.c
On 12/19/10 06:43, Ralf Wildenhues wrote:
> What you can do now is either
> - require your users to pre-initialize variables, or
> - ship a header fragment to be included first, that sets the needed
> variables.
Yeah, that's what we currently do in a few occasions, but I can't sell that to
other
Hi Stefano,
Thanks for the prompt reply.
On 12/18/10 05:02, Stefano Lattarini wrote:
> Note that the *CLEANFILES variables cannot be used to remove directories,
> so, for your approach to be really useful in all cases (i.e. also be able
> to git-ignore generated directories easily), a similar se
Hi,
Currently, automake doesn't set any of the various *CLEANFILES variables.
Since the "+=" syntax is not portable when the variables are not initialized
(and causes an automake warning), this leaves no option for Makefile.am
snippets from various tools other than using the *clean-local targets t
On 12/16/10 18:19, Stefano Lattarini wrote:
> Hello Ralf and Behdad.
>
> On Wednesday 17 November 2010, Behdad Esfahbod wrote:
>>
>> On 11/13/10 03:00, Ralf Wildenhues wrote:
>>>
>>> You are the first person to report this in the 12 months since we
>
On 07/29/10 02:26, Mike Frysinger wrote:
> i'm ok with a warning about the dir not existing (i.e. errno == ENOENT) and
> so
> it'd skip it, but the fatal abort is obnoxious. if it were some other reason
> (e.g. errno == EPERM), then i'm also ok with it aborting. this is what many
> other comm
Hi,
Hope you're all doing well.
So this tiny issue has been bugging me for years. Thought I report. Can you
please make aclocal silently ignore include directories that do not exist? It
bothers me that on a new system when I set my env vars to have a complete tree
in my ~/.local, every directo
Ralf Wildenhues wrote:
> * Behdad Esfahbod wrote on Mon, Oct 06, 2008 at 11:31:29PM CEST:
>> Ralf Wildenhues wrote:
>>> * Behdad Esfahbod wrote on Mon, Oct 06, 2008 at 05:40:52PM CEST:
>>>> Ralf Wildenhues wrote:
>>>>> my-dist:
>>>&
Ralf Wildenhues wrote:
> * Behdad Esfahbod wrote on Tue, Oct 07, 2008 at 10:56:02PM CEST:
>> Right. So why is:
>>
>> AMTAR = TAR_OPTIONS="$(TAR_OPTIONS)" ${SHELL}
>> /home/behdad/src/git/fd.o/cairo/build/missing --run tar
>>
>> not backward-co
Ralf Wildenhues wrote:
> * Behdad Esfahbod wrote on Mon, Oct 06, 2008 at 05:40:52PM CEST:
>> Ralf Wildenhues wrote:
>>> my-dist:
>>> env TAR_OPTIONS="--owner=0 --group=0" $(MAKE) $(AM_MAKEFLAGS) dist
>>
>> Thanks. Done now. Would be nice i
Ralf Wildenhues wrote:
> Hi Behdad,
>
> thank you for you helpful feedback! Addressing parts of it:
Hi,
Thanks again for the reply.
> * Behdad Esfahbod wrote on Fri, Sep 19, 2008 at 01:22:54AM CEST:
>> Also may be a good idea to instruct tar to not record uid of the
Hi again,
We're finally getting that cairo snapshot out, so here's some rambling about
"make dist" improvements:
- Sticky bits:
We've had problems before that cairo tarballs have included files with sticky
bits set. So we added a rule ourselves to clean up of any sticky bits. But
since I see
Ralf Wildenhues wrote:
> * Behdad Esfahbod wrote on Wed, Sep 17, 2008 at 08:40:31AM CEST:
>> Ralf Wildenhues wrote:
>>> Not sure what you're after here. The tools themselves will bail out
>>> anyway if they are too old (discounting automake 1.4 here). What
On Tue, 2008-04-15 at 20:09 +0200, Ralf Wildenhues wrote:
> Hi Behdad,
Hi Ralf,
Thanks for the quick response.
> * Behdad Esfahbod wrote on Tue, Apr 15, 2008 at 07:39:19PM CEST:
> > In short, all cairo source is C code, except for the BeOS backend that
> > is C++. So we have
Hi,
In cairo we are facing a bug in the no man's land between automake and
libtool. Reporting here anyway.
In short, all cairo source is C code, except for the BeOS backend that
is C++. So we have a block like this in our Makefile.am:
beos_headers = cairo-beos.h
beos_sources = cairo-beos-surfa
Hi,
I have a script like this:
function add_prefix() {
local PREFIX=$1
export PATH="$PREFIX/bin:$PATH"
export LD_LIBRARY_PATH_HACK="$PREFIX/lib:$LD_LIBRARY_PATH_HACK"
export CPPFLAGS="-I$PREFIX/include $CPPFLAGS"
export CFLAGS="-I$PREFIX/include $CFLAGS"
export CXXFLAGS="-I$PREFIX/inc
On Thu, 2007-06-21 at 20:24 +0200, Ralf Wildenhues wrote:
> * Behdad Esfahbod wrote on Thu, Jun 21, 2007 at 01:42:18AM CEST:
> > On Tue, 2007-06-19 at 09:18 +0200, Ralf Wildenhues wrote:
> > >
> > > All fair. Except I simply don't see a use case for this yet, no
On Tue, 2007-06-19 at 09:18 +0200, Ralf Wildenhues wrote:
> * Behdad Esfahbod wrote on Tue, Jun 19, 2007 at 12:13:17AM CEST:
> > On Sun, 2007-06-17 at 14:31 +0200, Ralf Wildenhues wrote:
> >
> > > If you can live with $(EXTRA_PROGRAMS) also
> > > containing the
On Sun, 2007-06-17 at 14:18 +0200, Ralf Wildenhues wrote:
> Hello Behdad,
>
> * Behdad Esfahbod wrote on Sun, Jun 17, 2007 at 01:02:27AM CEST:
> >
> > For the first time I'm stuck with an automake problem and think it's an
> > unfair limitation of autom
Hi Automake hackers,
For the first time I'm stuck with an automake problem and think it's an
unfair limitation of automake rather than my skills being short.
The problem is, the make check target that automake generates builds and
runs $(TESTS), but on systems with non-empty EXEEXT this doesn't w
24 matches
Mail list logo
