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
Tom Lord <[EMAIL PROTECTED]> writes:
>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
On Thu, Oct 24, 2002 at 06:50:42PM -0400, Paul D. Smith wrote:
> %% Tom Tromey <[EMAIL PROTECTED]> writes:
>
> Tom> If you do things right, your Makefiles don't need to contain
> Tom> specific filenames at all, and you don't need to edit any
> Tom> Makefiles as you add, delete, or rename fil
> 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
Re: glob v. list
Why not provide both mechanisms, and let people use what they want?
Personally, I've been bitten far more often with globs and would tend to
explicitly list files. But that's my "policy" decision and this is really a
"mechanism" question.
H
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.
%% Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> If you do things right, your Makefiles don't need to contain
Tom> specific filenames at all, and you don't need to edit any
Tom> Makefiles as you add, delete, or rename files
tom> Long-time automake readers already know I'm strongly against t
[ back to automake for this one ]
> "Tom" == Tom Lord <[EMAIL PROTECTED]> writes:
Tom> Also in defence of the `sh + make' approach:
Tom> GNU make can do lots of useful globbing and set manipulation of file
Tom> lists.
Tom> If you do things right, your Makefiles don't need to contain
Tom> sp
> 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
> 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?
People can probably get pre-built binaries of Bas
| The graph of interproject dependencies, including version-specific
| dependencies, is very complex -- bordering on intractable.
|
| Do the developers of autoconf believe this is true?
I don't. I'm not interested in this thread either.
Thien-Thi Nguyen wrote:
sounds about right -- finding the appropriate mux point to pinch is indeed the
first step towards sanity. if you get funding, give me a buzz. otherwise, i
will continue to work w/ (old) librx and approach the problem from the guile
perspective. (e.g., below is lex.test w
You need to be able to compile the bootstrap packages in minimal
environments, in order to get a very basic GNU environment.
I don't think we should do this at all. The smallest version of the
GNU system need not be "minimal", and making it so would be extra
work, so we should not.
B
> 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
From: Dan Kegel <[EMAIL PROTECTED]>
Date: Mon, 21 Oct 2002 10:51:51 -0700
You think the world is ready for Guile?
guile is not ready for the world. current install practice spews .la
and .so files all over $libdir and uses an internal "bugfixed" copy of
libltdl (if my reading of the cvs
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
sounds about right -- finding the appropriate mux point to pinch is indeed the
first step towards sanity. if you get funding, give me a buzz. otherwise, i
will continue to work w/ (old) librx and approach the problem from the guile
perspective. (e.g., below is lex.test w/ a simple shell-lexer sp
Tom Lord writes:
> But to _extend_ with new features or simpler approaches: that's where,
> for example, depending on GNU Make can make a world of difference.
So you're talking about Automake. I agree, Automake's attempts at
portability are nuts. But for the bootstrap packages you wouldn't even
> 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
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
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
Dean Povey wrote:
>
[snip]
> >Maybe I am the one now who is totally not getting it, but:
> >
> >How could you distribute a binary to run on all the different kinds of
> >systems? I use Cygwin and MinGW. Am I going to be excluded from Open
> >Source packages because the package maintainer decided
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.
Problem is that by the time you've figured out how to do that,
you're most the way done. Now, if you depended u
On Tue, 15 Oct 2002 05:38:49 +1000
Dean Povey <[EMAIL PROTECTED]> wrote:
> >How could you distribute a binary to run on all the different kinds of
> >systems? I use Cygwin and MinGW. Am I going to be excluded from Open
> >Source packages because the package maintainer decided not to provide
> >su
>> (im not an expert on autotools and this may sound simplistic, but
>> FWIW) Ive often wondered why ./configure has to be a script, i
>> understand it has to be portable, but couldnt the build tools compile
>> a binary that calls on a c library that provides most of the
>> functionality.
>
>Mayb
On Sun, 13 Oct 2002 15:57:46 -0400 (EDT)
Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Hello, Tom!
>
> 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 than 500k. Uncompressed sources o
> 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
> 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).
Pavel Roskin wrote:
> For example, there are two libraries, A and B, and only one can be used.
> There are at least (not counting --with-A=/path/to/A) 2 possibilities for
> each library (present and absent) and 3 possibilities for each option,
> (--with-A, -without-A, no option), which makes 36 c
Hello, Tom!
> 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.
Maybe I'm missing something, but portable code is easier to maintain.
It's a si
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
Tom Lord wrote:
>
> I personally pretty much agree with the larger picture you propose --
> but we can separate concerns.
>
> Forking the build tools projects is orthogonal to any particular
> direction to take the non-bootstrapping fork.
I don't think it orthoginal. If you separate them, then
I personally pretty much agree with the larger picture you propose --
but we can separate concerns.
Forking the build tools projects is orthogonal to any particular
direction to take the non-bootstrapping fork.
-t
From: Bruce Korb <[EMAIL PROTECTED]>
Organization: Home
X-Accept-Lan
> 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
Tom Lord wrote:
>
> * Maintaining the build tools (autoconf etc) is currently too hard.
>
> The maintainers have to struggle to write portable shell code;
>
> Those constraints really matter to a small number of packages (the
> "bootstrap packages") but could be reasonably relaxed for other
Tom Lord wrote:
> are already installed. Call this set the "bootstrap packages".
>
> Let's then formally identify a _subset_ of the bootstrap packages,
> which are those GNU tools that other (non-bootstrap) GNU packages are
> allowed to depend on for the build process. For example, GNU Make
> w
* 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
46 matches
Mail list logo
