llion config options. Many (but not all) of these options
should be in a site-wide policy file, but, because they're
specific to the one package, they don't belong in config.site.
I had patches for this at one point. I'll see if I can dig them
up.
--
| | /\
|-_|/ > Eric
table this is, but I'd be willing to bet its
portability closely correlates with that of "cp -r" :-)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
Nobody ever got fired for buying Microsoft -- but they could get
fired for relying on Microsof
't one of the process's gid's; I
can't remember whether BSD also has this restriction, or whether
it *always*, unconditionally, propagates it. I think the
latter...)
> I don't thing the sticky tag changes 'setgid'
> behaviour of a directory.
It does
really have an opinion on whether system-specific hints
belong in INSTALL; I can see the arguments both ways. But they
do belong *someplace*! The obvious place would be a FAQ, or a
"Hints" page on the autoconf site; if the latter existed, INSTALL
would only need to provide the URL.
-
-file
but if grep ever becomes like GNU sort, and considers the \n to
be part of the line, it'll stop working.
> +if diff /dev/null /dev/null >/dev/null 2>&1; then
If you don't have a /dev/null, but do have write permission on
/dev, this test will succeed. Perhaps a cor
ere's a rule about a library name
being only one word :-/
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
gful opinion. But it should
be chosen for a better reason than political pressure (even if
the pressure was applied indirectly, ie. to another project).
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, thi
gt; find more systems with Perl than with a working C++ compiler.
FWIW, there's also more likely to be a binary Perl distribution
than some of the others. Perl lists 50 or so platforms either
with binary distributions, or with Perl included in the
distribution. Python lists 17.
--
| | /\
On Fri, Apr 20, 2001 at 02:52:08PM +0200, Lars J. Aas wrote:
> Does such a thing exist? Should it be a goat?
> I'm thinking of something to stick on the web pages...
Hercules slaying the hydra :-)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED
can't be implemented to assist them, then perhaps they should be left on
> their own.
But this is most unhelpful. It's the stance that gave the world
ActiveX.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
date" variant
would still let them be used when building the distribution,
which would violate the whole point of tagging the release. By
giving you a pristine sandbox, the "checkout" variant guarantees
that *only* CVS-tracked files, and *precisely* the tagged
revisions of those files, w
7") which are probably still in
production on many machines.
Paul again:
> #if !HAVE_WORKING_VFORK
> # define vfork fork
> #endif
>
> and then use "vfork" uniformly in the later code.
For the above reasons, I think it would be a bad idea to use
vfork() instead of fork() w
ng fork.
I'd be amazed if anyone could manage an AmigaOS fork!
> (This vfork business should all be discussed clearly in the autoconf
> documentation, of course -- if anything about vfork can be discussed
> clearly. :-)
Indeed.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
very #include, wrapped or not,
should have the reason for that decision documented.
Wrapping everything is technically overkill, and more work
(though maybe not if you factor in the documentation), but it's
dead simple.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PR
On Tue, Jun 12, 2001 at 02:17:32PM -0700, Paul Eggert wrote:
> > From: Eric Siegerman <[EMAIL PROTECTED]>
> > Date: Tue, 12 Jun 2001 15:02:58 -0400
> >
> > you can get away with:
> > #define a b
> > (or the equivalent using true functions) only
gt; >a vfork() should do the job as well
>
> I don't see why this case would ever happen in real code.
Something which you'd prefer to have happen in parallel if
possible, but if it's not possible, then sequential is ok.
"Make" firing off a bunch of compil
xample.
>
> The increase in parallelism would be quite small for that application,
> because the extra parallelism would apply only between the fork and
> the exec;
Doh! Thanks.
> > From: Eric Siegerman <[EMAIL PROTECTED]>
> > Date: Wed, 13 Jun 2001 17:27:35 -0400
>
On Mon, Jun 18, 2001 at 03:29:17PM +0200, Rüdiger Kuhlmann wrote:
> [fork + vfork + ac_fork + ac_vfork]
>
> I guess you know _I_ agree, but "the others" don't seem so.
Suits me just fine.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECT
s/a/a/'
> aaa
> bbb
aaa
> ccc
bbb
>
ccc
$
To be truly robust, I'd want to label each command and response
with some unique id, and have the client (ie. configure) verify
the response's id. Starts to sound li
On Mon, Jun 18, 2001 at 10:17:04PM +0200, Tim Van Holder wrote:
> [...] "Function Portability" seemed like better English [than "Functions
> Portability"]
It is.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficie
d
compatibility is less of an absolute requirement.
- On the other hand, it probably DOES make sense to use
autoconf with cons, and you can probably start doing so in
small ways without a lot of effort. Simply identify a few
system-dependent facts that autoconf can figure out mo
fter auto* bugs, if it turned out it was
something else entirely that originally trashed your machine.
But ONLY if you have a disposable system -- I'm not for a moment
suggesting that you try it again on your server! (I for one
wouldn't be brave enough to try it even in a chroot jail on a
t;
Now, these annoying complaints from FreeBSD's mv are also another
question, and may in themselves be reason to move to cp+rm...
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
lity. ;-)
Bad idea to ship that of course, as the smiley acknowledges. But
in terms of building the list of functions needed by each
subcommand, this might be just the ticket. Omit some function
from libbb (do NOT replace it as I described above); then just
keep tweaking the dependencie
easily in an Autoconf macro as in the application(s).
Purely theoretical for me -- I don't expect to ever use an IBM
mainframe again -- but it seems to be of practical import to some
folks.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been a
akefile is missing.
Yes, please!
> If "rm Makefile" is the the last thing that "make distclean" does,
i.e. autoconf guarantees that Makefile be the last file listed
in @configure_targets@, and Automake put that macro at the end
of distclean-local or whatever it's called,
> then this alternate proposal is more robust than the method you
> proposed.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
"Outlook not so good." That magic 8-ball knows everything!
I'll ask about Exchange Server next.
- Anonymous
hypothetical new package
can then worry about the encapsulation layer that hides them from
the application programmer.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
"Outlook not so good." That magic 8-ball knows everything!
I'll ask about Exchange Server next.
- Anonymous
interrupted the "make distclean";
> Paul> if there was more work to do, another "make distclean" would
> Paul> still do it.
>
> IIUC, you're saying config.status --clean should end with the top
> level. I agree.
And, if asked to clean a subdirectory, should c
e to remove the Makefile last. This avoids the problem
> since "configure" is not removed. But once we have "./configure
> --clean", I don't see the point of having "./config.status --clean".
> As far as I can see, anybody who wants to invok
me regardless of context. The resulting
test-for-symlink command might be used in a context other than
the shell in which configure happens to be run.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
"Outlook not so good." That magic 8-ball knows
l
produce correct results without guessing.
(Background: gmake only uses setvbuf() to make stdout
line-buffered. I presume the reason is to make sure the output
from make and its subprocesses interleaves properly.)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTE
ecified in an
> argument to some autoconf macro.
>
> Then aclocal could just make symlinks in that directory to the
> appropriate files in the [automake] distribution. This would fit nicely with
> other tools that do a similar job (eg gettextize, libitize).
--
| | /\
|-_|/ >
implement the new process.
And then wait for those tools to reach critical mass :-(
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perh
es into non-text!
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
- Paul Schneider-Esleben
- Rather than trying to disable the verbosity in a highly
non-portable way, work around it in a portable (though ugly)
way:
abs=`cd $rel >/dev/null && pwd`
Hmmm, time for a CANONICALIZE_PATHNAME macro? Bonus: it could be
made to work with pathnames other than directo
E again, you maintain end users' isolation from
the autotools.
Your core developers will still be working from your CVS repo ...
but then, by the above argument, they'll have installed the
correct autotools versions.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL
d to deal with.)
Workaround: add this to pkg-root/distrib/configure.ac:
AC_CONFIG_AUX_DIR([.])
That defeats the search path shown above, which keeps automake
from seeing ../install-sh etc., and thus forces it to put another
copy directly into distrib.
--
| | /\
|-_|/ > Eric Siegerman, Toront
S_ONLN);
> if (nprocs < 1)
> nprocs = 1;
Rather:
if (nprocs == -1) /* Value unavailable */
exit(EXIT_ERROR);
else if (nprocs == 0)
nprocs = 1;
> printf ("%ld\n",nprocs);
> exit (EXIT_SUCCESS);
> }
Then if it exits with an error, proc
default group.
I wonder what POSIX has to say about this?
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".
" to fix that, but I bet there are other versions
of ls that choke on it :-/
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".
mentioned, a newly created file inherits
its group from its parent directory.
- on SysV/POSIX'ish systems, in a directory *without* setgid, a
file's group is initialized to the creating process's
effective gid; that's the behaviour you're used to seeing.
--
|
idea -- it sounds rather cool
-- just pointing out one of the costs.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".
ds $LINENO, so configure.lineno
substitution shouldn't have been done in the first place.
That it was, was due to a weird interaction (whose details I
forget) between the two shells' $LINENO decision-making, and
some information being lost somewhere along the way.
Ex
neither
adapt-or-die nor compatibility-at-all-costs is a reasonable
attitude. In practice, it's often a tradeoff.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".
S' for yacc, and
> `LFLAGS' for lex, are exceptions to this rule, but we keep them
> because they are standard.)
So CC/CFLAGS is perhaps not the most important pattern to stay
compatible with.
(To be honest, I don't really feel that strongly about FXX vs.
FC; really, my points
e the appearance of having frozen Fortran support
> back in 1977.
:-)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".
exit 0
- the parent configure.ac could check for the existence of some
generated file in the subdirectory, as someone else suggested
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".
factor out optional subcomponents of a package. It's a single
change that's sufficient to handle a wide set of similar cases.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".
nd it's a
change that's pretty unlikely to cause any merge conflicts when
you upgrade the library.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
Just Say No to the "faceless cannonfodder" stereotype.
- http://www.ainurin.net/ (an Orc site)
/bin/sh too!
Linux systems typically have bash as /bin/sh, so the script's
success there is unsurprising.
By "(tcsh shell)" I presume you mean it's your login shell.
That's irrelevent; what matters is the one named in the script's
"#!" line.
--
| | /\
|-_|/
uld
be to edit this into the configure script at some point after the
LINENO machinations:
ps | grep "$$" >/dev/tty
Alternatively, send that command's output to config.log. (Is there
a sanctioned way to do so?)
[1] See Tom Christiansen's "Csh Programming Considere
On Fri, Feb 14, 2003 at 02:32:42PM -0500, Thomas E. Dickey wrote:
> On Fri, 14 Feb 2003, Andreas Schwab wrote:
>
> > Eric Siegerman <[EMAIL PROTECTED]> writes:
> >
> > |> [ksh doesn't support "=="]
> >
> > Since pdksh supports "
Even if I *had* noticed those "[[" and "]]" in the
man page, I'd probably have written them off as more botched
troff.
Thanks for pointing it out. Of course now I have to try to
forget it in the interest of portable shell-scripting, just like
the rest of the ksh goodies...
el would be a happy medium?
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
A distributed system is one on which I cannot get any work done,
because a machine I have never heard of has crashed.
- Leslie Lamport
On Wed, Feb 19, 2003 at 01:51:01PM -0800, Paul Eggert wrote:
> Eric Siegerman <[EMAIL PROTECTED]> writes:
> > [The "regression" test for shell-function support] first appeared in 2.55, in
>mid-November, 2002 (not
> > counting betas). How long would it be a
able. On Solaris 7, the closeest
equivalent seems to be "strip -x": "Do not strip the symbol
table; debugging and line number information may be stripped."
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
When I came back around from
K,
they're specific to GNU make. (Which is to say, I know they were
invented in gmake; my only uncertainty is that a few other make
variants might have picked them up.)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
When I came back around from the dar
f it's
a V7ism, fine; but if there are relevent platforms in which
that's not the case, then:
chmod u+w builddir/FILE
would be safer.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
It must be said that they would have sounded better if
rrected.
Of course, the people who wrote those incompatible ls's should be
; "-rwxrwxrwx" format output
*absolutely* goes back to V6.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
It must be said that they would have sounded better if the
from a function, and whether
or not the script is running in a broken shell
Then mention in the docs that the line number is
function-relative on older shells.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
It must be said that they would have sounded b
TRL-M, which is often invisible, but still causes breakage.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
uickly see whether your
evals and variable substitutions expanded to:
prargs a b c
or:
prargs "a b c"
or:
prargs a "b " c
The blurb's twice the size of the program itself :-/
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.
oconf's Makefile.am's, or
in Automake's processing of a correct Makefile.am, I wouldn't
know.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band
63 matches
Mail list logo
