lable.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/ma
hen run without the cache?
Is it possible to find bounds on which results can alter which results?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an
I personally spent quite a significant amount of time fixing a few
configure.{ac,in} files in various packages, but in the end, we gave up
with this idea and no longer use the autoconf cache.
If we use the cache for standard tests only, could that fix this
problem?
--
Dr Richard
autoconf, and specially by
> those executed within pkgsrc.
There might be things to share/fuse. I have not looked at it
at all.
--- End Message ---
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That'
whenever certain
packages are installed.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call
__
FWIW, I think we should only use a new Autoconf if it is a patched
variant of the same version of Autoconf we use today.
I too would be in favor of using a patched Autoconf -- or just applying
the same change directly to the configure file.
___
Thank you. Can you help us regenerate the Emacs configure file
using this patch?
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
an's message
of "Sat, 28 Apr 2007 14:35:34 -0400")
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Richard Stallman <[EMAIL PROTECTED]> writes:
> % ./configure
> as_func_failure succeeded.
> as_func_failure succeeded.
> No shell foun
Congratulations! Are you handing out cigars? ;-).
> 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
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
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
PS to autoconf: I finally got remote CVS working from my home machine
to the autoconf repository at subversions (or is it savannah?), which
means I no longer need to bother other autoconf maintainers to install
minor changes like this one.
That is good.
The INSTALL file does not have any of those things. It launches
straight into the installation instructions without any title or author.
Please put the copyright notice and permission notice at the top of
the file.
The copyright notice and permission notice should not go in a separate
section. They should go in the standard place, on the page after the
title page if there are such things, or just after the title and
author attribution.
This change (or something like it) needs to be installed at gnu.org.
I guess I can install the change in the master copy, but I don't know
how it gets propagated after that.
You should run the makefile in /gd/gnuorg so as to recreate
standards.text. But please handle standards.texi a
It's currently 226 lines, 1366 words, and 9221 bytes.
At that size, it may as well have a simple permissive license, as you
suggested. However, the wording should be different:
Copying and distribution of verbatim and modified versions of this file
is permitted in any medium provide
Thanks for noticing the problem.
+The @file{INSTALL} file is free documentation; the Free Software
+Foundation gives unlimited permission to copy, distribute and modify it.
There are two possibilities. If the file is big enough, it should use
the GFDL. Otherwise, what you have in mind
I'm not sure I know what was being meant here for sure either but my
interpretation is that configuration items such as the CC and CFLAGS
Make variables (which are as I say unfortunately sometimes taken from
the environment) have the nature of being variables
This is starting to m
The GNU coding standards explicitly specifies the possible configure
options. Whatever names we choose for new options, they will have to
be given in the coding standards. They will not be exceptions, they
will be defined options.
I agree, and this is why I proposed to move the foodir into
Hence, we need an open scheme, so I think --VAR=VAL is wrong, there is
way too much risks to confuse actual options with variables, or to
forbid any extension in the future.
I think you are right--if we use options, the option name should not have
to be the same as the variable name.
XEmacs already uses --with-cc and --with-cflags, although I'd tend to go
for the shorter --cc=sun-cc and --cflags=-O2. You'd also need --cxx and
--cxx-flags; I'm not sure what other environment variables are similarly
special.
If we go in that direction, should we say that ALL th
> Yes, thank you, I know this. This is what I do. But pardon me, this
> is by no means something I consider ``natural''.
I said this is the natural way to "follow the spec". Whether it seems
entirely natural as a way to do the job is not the question.
We are not going to change the
CC=sun4-cc ./configure
Hence, next time configure is run, it forgets about the CC which was
used to build config.cache, and you get an inconsistent system.
So configure needs the user to tell things instead of doing stuff in
its back. Hence
./configure C
> We will stay with the --foo syntax for configure options. We should
> not change the configure syntax incompatibly unless there is a
> pressing need for a change.
Please reconsider. There is a pressing need for a change. People
currently have to use work-arounds such as:
Back in December we agreed to move Autoconf to subversions,
but it was delayed, and seems not to have happened yet.
Can we move it now?
So since configure supports VAR=VAL, since this is a perfect scheme
which is completely extendible, I was noting that this scheme was
enough to support all the foodir variables we might need.
We will stay with the --foo syntax for configure options. We should
not change the configure
Let me take the example of a2ps. a2ps uses a configuration file which
is installed in syscondir. To find it the path is hard coded in a2ps,
and a natural means to do that would be
AC_DEFINE_UNQUOTED([A2PS_CONFIG_FILE], ["$sysconfdir/a2ps.cfg"])
The natural way to implement it a
However on systems with shared libraries you can't just "promote" a
linked program from /usr/bin to /bin -- you have to link it statically
-- i.e. the build has to know from the beginning that you're intending
to use the result at run-time from single-user mode.
Why is that? Don'
> * What about other related Make variables, such as *dir?
> Should they all be configure time options too?
Yes, and, in fact, they already are.
Not always. They are configure-time options in programs that
use Autoconf, and nowadays that may be most programs.
But *requiring* these o
For instance, if we do decide to support some --docdir, or --htmldir
etc., in a large tree with several configures of different generations
(which is always likely to happen), then outer configures might pass a
--htmldir which an inner configure won't understand, and it will choke
Alexandre> Of course, sometimes it's convenient to change these
Alexandre> options at build time, but the potential for trouble is
Alexandre> such that I wouldn't recommend this practice.
I would even prevent this practice, make it invalid.
I am not sure exactly which practice yo
> No, in GNU these programs should not be in /usr/local, because they
> *are* "the system".
Ah, yes, exactly. Except that even the GNU System has add-on
third-party packages and indeed I believe, correct me if I'm wrong, that
it is the practice on GNU systems to use /usr/loca
Call it what you will, but that's explicitly what I mean -- a variable
that will provide a prefix where all installation activities will occur
but which will be invisible (i.e. not used) during run time.
This sounds exactly the same as what exec_prefix does now.
I see you THINK you ar
It's common to have packages that generate header files out of
configure options. If prefix changes from configure to build time,
the header files end up incorrect.
That would be a bug, according to the present spec.
Ok, so the right thing to do is to generate the header files a
It's a common complaint that people can
./configure
make prefix=/foo
make install prefix=/foo
Why would anyone complain about this? Please explain
what you think is a problem.
People should *not* be allowed to do this (i.e., it should fail),
decisions should
In some respect I see the current defaults, starting with `--prefix=\
/usr/local', as in some way supporting the *BSD systems since that's
more or less what their heir(7) manual page says.
It has nothing to do with *BSD in particular. People running GNU
programs on non-GNU systems ge
Anyway, making this option an install-time option is probably not a
good idea. Many programs will want to know, at compile-time, where
the configuration files are going to be installed. If they just take
sysconfdir from build time, they'd look for them in /usr/etc, instead
of
I'm OK with having as many --foodir as people might want (and
actually, I'd like to suggest that we recommend
./configure prefix=/usr
This is inconsistent with the normal command line option syntax.
We should stay with -- for consistency.
Systems that want to
arrange for sysconfdir to be /etc when --prefix=/usr just have to
install /usr/(share|etc)/config.site with:
test "x$sysconfdir" != 'x${prefix}/etc' || sysconfdir=/etc
I think you have misunderstood what I proposed, because this would not
implement it. We
By giving ultimate flexibility in the way you describe the devloper is
also free to muck with the defaults and to make even greater mistakes in
mis-classifying the files he's trying to install.
Developers can make all sorts of mistakes. The mistakes just have to
be fixed. Developers
Either that or one gives up on the sillyness of allowing the user to
choose the actual name of the prefix and instead simply encode the
expected defaults for various platforms into Autoconf (i.e. /usr,
/usr/pkg, /usr/local, or whatever) and allow the user only to specify
whethe
I dislike the idea of this kind of hard coding. I'd much rather use
./configure --prefix=/usr --sysconfdir=/etc
I think this makes it hard to get an option that more and more users want.
So prefix=/usr leads to syconfidir=/etc, but prefix=/usr/gnu (not my
idea) leads to sysconfdir=/usr/gnu/config? Ugh.
This nonuniformity is precisely the intent. When prefix is a
subdirectory of /usr, such as /usr/local, people are likely to be
unhappy with installing the configuration fi
Are all of the relevant developers subscribed to the list,
No. We need to talk to a larger group.
How would one
best measure the responses?
Not by counting who thinks what, but by seeing what problems people
mention and then judging how severe they are and what could be
done to
> Here is an idea. Suppose that the default for sysconfdir were computed
> from the actual value of prefix, as follows:
>
> If prefix is `/usr', use `/etc'.
> Otherwise, use $(prefix)/config.
I think we need to ask the community of developers what they would
think of
> Why do you think `make install' should not install them in /etc?
Because `make install' is not supposed to install anything outside
--prefix. As I wrote before, people often install software as
non-root, and it's a nuisance when `make install' fails because the
software ina
> So the only question is, should we change the default for --sysconfdir?
Only if we also specify that packages shouldn't install anything in
sysconfdir with `make install', only with `install-sysconf'.
Why do you think `make install' should not install them in /etc?
If there had been a separate "--localconfdir" choice I would have been
able to decide, on a per-package basis without having to patch it,
whether or not I wanted it to live under /usr, or /etc, or wherever.
I think you are mixing two issues that ought to be separate.
1. Whether the p
Which reminds me: $(sysconfdir) should never include $(prefix). If
there's a common need for a configuration directory under $(prefix) then
it should be represented by $(localconfdir) or some similarly named
variable.
This is a question I would like people to discuss more
so we
Whether to use /usr/share/doc instead of /usr/doc is a decision I will
have to think about. "Standards" written for the GNU system by people
who are not participating in the GNU Project, and who don't even
recognize that the system is GNU, have no authority here. Please do
not change this now.
51 matches
Mail list logo
