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

Re: [RFC] GNU autoconf and dpkg-architecture

On Tue, Feb 05, 2002 at 11:08:50AM -0200, Henrique de Moraes Holschuh wrote:
> > Ok, I asked RMS, who is responsible for such things (at least whenever he
> > likes to be :).  There might be some issues with some packages if you
> > specify --build although you are not actually cross compiling.
> Even when --build is equal to --host ?  And are those issues something we
> will suffer in Debian, or are they just the usual braindamage we find
> everywhere and fix in Debian?

If I would knew what could happen I would be specific about it.  Frankly, I
don't know.  It might be all fine to dpecify --build and --host all the
time, even if not cross compiling.  It might be fine with all package from
some specific autoconf on.  If it happens, it will likely be a bug in the
packages configure.in or so.  I don't think it would be all too bad to try
it out and see what breaks (and fix that), but I feel more comfortable if we
have some safebelts to offer in case of the unexpected.
> > So, the recommended way is to do
> >   confflags += $(DEB_HOT_GNU_TYPE)
> Something seems to be missing here :)

See my other reply, where I offer three alternatives.  It turns out that
your suggestion will work best, as it works for all versions of autoconf.
I also have developed a "smart" version for autoconf 2.13 and one for
autoconf 2.52 (and later).

I think it is reasonable to use your approach of specifying both by default,
but keeping the smarter alternatives around for people who want or need

> > About all other things in your reply: I agree, good idea, more power to you,
> > and let me know if I can be of help :)  [Indeed I think that lintian can be
> > of help, at least to gather the raw data]
> The Debian lintian lab is basically all source packages unpacked, thus a
> grep-friendly place to search for stuff :)

Yes, this is very useful.  Search for all occurences of "dpkg-architecture",
the DEB_ variables involved, and for --print-architecture,
--print-installation-architecture and --print-gnu-build-architecture.  Those
three latter options are quite obsolete except for backward compatibility
fallback solutions, and it would be nice to have the raw data where they are
still used (if you don't want to fix those packages as well, send the data
to me, please).


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

Reply to: