> Also, the fork is not really the main issue. The main issue is what
> to fork _to_.
I confess, it was an indirect attempt, mostly hoping to build on:
> nobody's really happy with the current status
which I pretty much agree with.
> You like GNU Make, others
> From: Tom Lord <[EMAIL PROTECTED]>
> Date: Sun, 13 Oct 2002 09:30:13 -0700 (PDT)
>
> I would expect these forks to be very stable,
> tending mostly to be simplified over time.
I don't expect that. On the contrary, many of the macros recently
added to Autoconf (and even-newer macros stacked up
Here's a quote from "another list" that illustrates a problem with the
auto* approach to release mgt:
> I'm looking at trying to get autoconf to detect the right version of
> BDB (need to export some SVN_FS_GOT_DB_MAJOR variants), and getting
> the checks just right proba
Amanda’s (TEARS)
Homepage: http://www.a-m-y.ch/ !
Und nicht vergessen…. GB EINTRAG!!! Danke für Deine
Unterstützung!!!
On Tue, Oct 15, 2002 at 11:43:20AM -0700, Tom Lord wrote:
>
> Perhaps. What I specifically remember is conditional code for VMS in
> some of the earlier packages.
ifdef's are not autoconf.
--
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net
Perhaps. What I specifically remember is conditional code for VMS in
some of the earlier packages.
The choice of shell features permitted in auto* scripts, as someone
else recently pointed out, is a clear example of the original
bootstrap considerations impacting more packages than there is any
On Tue, 15 Oct 2002, Tom Lord wrote:
> A de facto set of bootstrap packages already exist. autoconf was
> first built for those packages, and it was used to make them
> extraordinarilly portable (to all unixen, VMS, and several systems
> you've all but forgetten about).
I've never seen the port
>> Let's (more formally) identify a _small, finite_ set of GNU
>> packages that should be maintained in such a way that they
>> can be built in many environments (or for native GNU
>> systems), even if no other GNU tools are already installed.
>> Call this set
$B!!(B<$BAw?. $B%o%s%@!<%i%$%U!!:45W4V(B
$B!!G[?.Dd;_!'([EMAIL PROTECTED]
$B!!FMA3$N%a!<%k$NG[?.?<$/$*OM$S?=$7>e$2$^$9!#(B
$B!!$3$l$O(BWEB$B>e$K%"%I%l%9$r8x3+$5$l$F$$$kJ}$rBP>]$KG[?.$7$F$$$k9-9p(B
$B!!%a!<%k$G$9!#:#8e0l@Z$N%a!<%kG[?.ITMW$NJ}$O$3$N%a!<%k$r$=$N$^$^(B
$B!!$4JV?.$/$@$5
Am I the only one or does the Subject seem a little misleading?
On Tue, Oct 15, 2002 at 05:38:49AM +1000, Dean Povey wrote:
> The easiest way would be for ./configure to find the C compiler and build
> a simple utility binary from source, then use that for the rest of the
> configuration.
So j
> So you are proposing to trade in end user convenience (package builds on
> any system "out of the box") for autotools maintainer convenience
> (maintainers can assume a fixed environment). I don't think that's a good
> idea. It goes completely contrary to the goals of the autotools.
>
> In f
Tom Lord writes:
> * Maintaining the build tools (autoconf etc) is currently too hard.
> * Fork the build utils projects.
>
> Let's (more formally) identify a _small, finite_ set of GNU packages
> that should be maintained in such a way that they can be built in many
> environments (or for nativ
Glenn McGrath <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> Pavel Roskin <[EMAIL PROTECTED]> wrote:
>> If you are going to make a fork, add a well-behaving shell to the
>> requirements and leave out everything else. I know a project with
>> configure script longer
Andreas Buening <[EMAIL PROTECTED]> wrote around 14 Oct 2002
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> Even more, to my knowledge for systems like Cygwin, MinGW and EMX
> the configure time depends only on the number of fork() calls.
> I guess, it doesn't matter whether you have a shell scri
14 matches
Mail list logo
