Is there anything known to be non-portable about this technique for
generating a list of all included files?
cc [-I options] -E \
| sed -e '{
/^#[[:space:]]\{1,\}[[:digit:]]\{1,\}[[:space:]]\{1,\}"/!d
s/^[^"]*"//
s/"[^
* Maintaining the build tools (autoconf etc) is currently too hard.
The maintainers have to struggle to write portable shell code; they
have to constantly avoid the temptation to introduce new tool
dependencies in the wrong place; they can't even rely on GNU Make.
Those constraints really matte
> I guess this discussion is void - it is not about
> "forking". It is about creating your own set of buildtools
> and to try to reach a level of matureness that we see in the
> autotools today.
Yes and no.
Yes -- I have the nascent "package-framework" which has som
,
<mailto:[EMAIL PROTECTED]?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/automake/>
Date: Sun, 13 Oct 2002 09:57:23 -0700
X-UIDL: WE)"!V6*!!SKh"!B%X!!
Tom Lord wrote:
>
> * Maintaining the build tools (autoconf etc) is current
Ok, those would be your goals for the non-bootstrapping fork.
Aside from obvious goals (like, "cleaner, simpler, cooler")
my vague idea is:
I want to make it much easier to audit installations and to automate
package dependency handling. I want to make it easier to construct
multiple user env
> Uncompressed sources of ash with function support are smaller than
> that.
:-)
I've found that a few standard Posix tools, plus GNU Make, are a nice
combination (c.f. the `package-framework' via anonymous ftp from
regexps.com -- not that the framework is anywhere near done).
> Tom seems resistent on a backfill library of headers and
> library functions
Uh...actually, that's part of the intention of `libhackerlab' -- also
at the regexps.com ftp.
-t
>> 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
any
good reason for.
-t
From: "Thomas E. Dickey" <[EMAIL PROTECTED]>
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
> extraordinarill
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
> 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
> It could be that we should tell people to use Bash to build
> GNU packages if their native shells have trouble handling the
> job. That would be a smaller change and perhaps worth doing.
How is `bash' built?
>> You need to be able to compile the bootstrap packa
Long-time automake readers already know I'm strongly against
this sort of structuring. This yields Makefiles which are
fragile and undependable. For instance, if you create a
temporary file with a "source-like" name in the source tree,
then the build fails.
> Why not provide both mechanisms, and let people use what they
> want?
`package-framework' (ftp.regexps.com) actually does this, by the way.
I emphasize the globbing option because it's what I use most often,
and what I think is usually best.
-t
> I just don't see it. Unfortunately I can't afford to spend
> time thinking about it. There is too much else that I have
> to do.
The GNU coding standards, and by extension the configure/build tools,
have a very large role in keeping GNU systems coherent and keeping it
p
Globbing can inadvertently lead to unwanted files being
compiled/distributed/deleted/whatever. If you accidentally
delete a source file, make won't complain because it won't
know.
I've played around a bit with an approach to globbing that solves (in
some sense) both p
16 matches
Mail list logo
