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
[ On Friday, September 15, 2000 at 16:29:04 (-0600), Richard Stallman wrote: ]
> Subject: [Autoconf] Re: HTML format documentation
>
> The GNU coding standards explicitly specifies the possible configure
> options. Whatever names we choose for new options, they will have to
>
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
[ On Tuesday, September 12, 2000 at 14:12:42 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> It is an incompatible change in the spec, and that is very bad.
There are ways to fix what might be called ``design flaws'' without
causing perm
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
> 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 specia
| So maybe something like
| --set-CFLAGS=-ggdb?
|
| That is a uniform scheme but not very convenient. Since all of these
| options would be designated by us, and we would make an explicit list
| of them, we don't have to limit ourselves to a simple uniform naming
| scheme.
Please, do
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
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> XEmacs already uses --with-cc and --with-cflags,
I don't like this at all: you don't even respect the name of the
variables! It means two things to learn: the name of the variable for
make, and the interface from configure.
Russ>
| 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
|
|
| > 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 g
Richard Stallman <[EMAIL PROTECTED]> writes:
> 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
> 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
On 11 Sep 2000, Akim Demaille wrote:
>
> | 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],
> "Guido" == Guido Draheim <[EMAIL PROTECTED]> writes:
Guido> Akim Demaille wrote:
>> See AC_ARG_VAR.
Guido> taken. ... then again, AC_CACHE_CHECK does not use
Guido> it
I don't understand what you mean. I agree some high level macros such
as AC_CHECK_PROGS should document their first
Akim Demaille wrote:
> See AC_ARG_VAR.
taken. ... then again, AC_CACHE_CHECK does not use it wouldn't that be okay?
Just again, what about a second-level options that go in another helpscreen, and,
well, in that respect, I do support your position to the point that the
current helpscreen is al
> "Guido" == Guido Draheim <[EMAIL PROTECTED]> writes:
Guido> As the discussion does now lead a bit elsewhere, what about
Guido> second-level options, settable via VAR=VAL (or sth. alike)?
Guido> There was the discussion that for cross-compiling, people do
Guido> often have the needs to pres
Richard Stallman wrote:
>
> The most
> important example is when `configure' is re-run (which is not that
> uncommon; re-running `./config.status --recheck' when configure.in
> changes is becoming more and more common): any such variables set in
> the command line are lost i
| Akim Demaille <[EMAIL PROTECTED]> writes:
| > please, tell me why you want that there are two different means to say
| > the same thing? Why do you want both
| >
| > ./configure --prefix=/foo
| > make
| >
| > and
| >
| > ./configure
| > make prefix=/foo
| >
Akim Demaille <[EMAIL PROTECTED]> writes:
> please, tell me why you want that there are two different means to say
> the same thing? Why do you want both
>
> ./configure --prefix=/foo
> make
>
> and
>
> ./configure
> make prefix=/foo
>
> ?
>
> If the Makefile
| > 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-arou
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Richard> Even a compatible change such as requiring all programs to
Richard> support the --foodir or --dir-foo syntax would be a hassle
Richard> for some programmers (those who don't use Autoconf), and the
Richard> change can take ye
| 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
> 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:
On Sep 10, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> 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 -
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
On Sat, Sep 09, 2000 at 10:19:53PM -0300, Alexandre Oliva wrote:
> The point of having binaries in `/bin' instead of `/usr/bin' is so
> that you can run them without mounting /usr. Instead of figuring out
> which shared libraries they depend on, copying them to /lib and
> remembering to do so eve
On Sep 9, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> 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
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'
Somehow we lost Richard from the thread, which is a pity since your
suggestion is good IMHO. Here's a copy of the message from Earnie.
--
--- Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> This is also why I know suggest this -
--- Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> This is also why I know suggest this --help:
>
> | Installation directories:
> | --prefix=PREFIX install architecture-independent files in PREFIX
> |[/usr/local]
> | --exec-prefix=EPREFIXinstall archite
| > There is something I like better in
|
| > ./configure --prefix=/usr bindir=/bin
|
| > over
|
| > ./configure --prefix=/usr --bindir=/bin
|
| What's wrong with:
|
| ./configure prefix=/usr bindir=/bin
|
| ? :-)
I'm very much in favor of such things, mainly beca
On Sep 8, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Richard> Not always. They are configure-time options in programs that
Richard> use Autoconf, and nowadays that may be most programs. But
Richard> *requiring* these options
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Richard> What about other related Make variables, such as *dir? Should
Richard> they all be configure time options too?
Alexandre> Yes, and, in fact, they already are.
Richard> Not always. They are configure-time options in progr
| 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 wi
Richard Stallman <[EMAIL PROTECTED]> writes:
> Eliminating the possibility of specifying them at make time would be a
> bigger change and an incompatible one. I think we agree we should not
> do that, but we should encourage people to specify these arguments
> at configure time instead of make ti
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
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.
Akim> I would even prevent this practice, ma
> * 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
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Sep 8, 2000, Russ Allbery <[EMAIL PROTECTED]> wrote:
>> I don't understand why this would be the case. Why can't the proper
>> run-time library search path be encoded when the binary or library is
>> built?
> Because on certain platforms this ju
On Sep 8, 2000, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> Unfortunately, it's not that simple, in general. For example, thinking
>> of libtool, on some platforms, shared libraries and programs that depend
>> on them have to be re-linked at install
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> Unfortunately, it's not that simple, in general. For example, thinking
> of libtool, on some platforms, shared libraries and programs that depend
> on them have to be re-linked at install time to have the proper run-time
> library search paths encode
On Sep 7, 2000, Russ Allbery <[EMAIL PROTECTED]> wrote:
> No, $(prefix) specifies the root of the package for whatever step you're
> performing. --prefix as an argument to configure says to configure the
> package with that root, $(prefix) in make says to build the package with
> that root (and
Greg A Woods <[EMAIL PROTECTED]> writes:
> [ On , September 6, 2000 at 21:57:04 (-0700), Russ Allbery wrote: ]
>> You need both;
> Actually no, as I tried to explain earlier you do not want to be able to
> adjust $(prefix) during any "make" execution, at least not the way many
> people use $(pr
Hi!
>--[Greg A. Woods]--<[EMAIL PROTECTED]>
> [ On , September 6, 2000 at 21:57:04 (-0700), Russ Allbery wrote: ]
> very different in what they do. Indeed it should be possible to adjust
> ${DESTDIR} during "make install" (and it would only have effect during
> "make install"). $(prefix) spec
[ On Thursday, September 7, 2000 at 05:51:44 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> We can think of /bin as a place where a few things get "promoted"
> which would normally be in /usr/bin. In the past, sysadmins often
> moved
[ On Thursday, September 7, 2000 at 05:51:46 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> Call it what you will, but that's explicitly what I mean -- a variable
> that will provide a prefix where all installation activities will occu
[ On , September 6, 2000 at 21:57:04 (-0700), Russ Allbery wrote: ]
> Subject: Re: HTML format documentation
>
> Paul D Smith <[EMAIL PROTECTED]> writes:
> > %% Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> >>> * Is the advantage big enough to justi
(I have cc'ed this mail to Daniel Quinlan, the FHS coordinator.)
Richard Stallman <[EMAIL PROTECTED]> writes:
> Unless the GNU System also wants to make the leap of eliminating either
> /usr, or /bin and /sbin, it's necessary to use (or at least imply the
> use of) "--prefix=/" to in
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
Paul D Smith <[EMAIL PROTECTED]> writes:
> %% Alexandre Oliva <[EMAIL PROTECTED]> writes:
>>> * Is the advantage big enough to justify the incompatible change
>>> of saying "You can't specify the prefix when you run Make"?
> This should always be explicitly _allowed_ during "make install", as
>
On Sep 7, 2000, "Paul D. Smith" <[EMAIL PROTECTED]> wrote:
> Either that, or DESTDIR should become a required feature of GNU
> installation.
> Actually, I kind of prefer the latter.
So do I.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer
%% Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> * Is the advantage big enough to justify the incompatible change
>> of saying "You can't specify the prefix when you run Make"?
This should always be explicitly _allowed_ during "make install", as
long as "make" has been done first.
Either t
On Sep 6, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> But then, what if someone
> starts a build with `prefix=/foo', modifies some files, then re-starts
> with `prefix=/bar'?
> Indeed, that would lead to bad results.
> I see the point you're making. If prefix were only a
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
Akim Demaille <[EMAIL PROTECTED]> writes:
> So it might be good to try to find an extensible scheme for directory
> specifications, something to parallel with --with and --enable.
> There are two ways to handle this: via `open options', just like
> --enable: we could recognize --foodir=FOO for a
[ On Wednesday, September 6, 2000 at 05:07:18 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> In some respect I see the current defaults, starting with `--prefix=\
> /usr/local', as in some way supporting the *BSD systems since that
[ On , September 6, 2000 at 14:19:23 (+0200), Akim Demaille wrote: ]
> Subject: Re: HTML format documentation
>
> >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> Alexandre> Of course, sometimes it's convenient to ch
| 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.
Yes, I agree. What I
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre explained very well something which concerns many of us.
It is hard to have this scheme work, and most packages have it wrong,
so basically you should just not rely on this (unless you are ready to
start again from scratc
On Sep 6, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> 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.
It's common to have pac
On Sep 6, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> But this does not necessarily mean it ought to be a configure-time
> option. It could be a build-time option like prefix and sysconfdir.
Indeed.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC
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.
%% Alexandre Oliva <[EMAIL PROTECTED]> writes:
ao> On Sep 5, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
>> My proposal is that if you do just `make install' then the default for
>> prefix and sysconfdir (and maybe some other variables) should be the
>> same as now. But `make ins
| On Fri, Sep 01, 2000 at 09:38:28PM -0600, Richard Stallman wrote:
| : 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,
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Sep 4, 2000, [EMAIL PROTECTED] (Greg A. Woods) wrote:
>> [ On , September 3, 2000 at 16:44:05 (-0300), Alexandre Oliva
>> wrote: ]
>>> Subject: Re: HTML for
| 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
| i
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Sep 2, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
>> 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 th
I forgot to say that if the user wants such magic stuff, we can
document how to write the proper config.site which does that. I am
personally against having configure encode such things, it should be
entirely under the control of the user.
%% Alex Hornby <[EMAIL PROTECTED]> writes:
ah> Richard Stallman writes:
>> I think we need to ask the community of developers what they would
>> think of this change. It sounds good, but it could have pitfalls
>> we have not thought of.
>>
>> Would someone like to do that?
ah> I
On Sep 5, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> My proposal is that if you do just `make install' then the default for
> prefix and sysconfdir (and maybe some other variables) should be the
> same as now. But `make install standard_system=yes' would use
> different system-specific
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
On Sep 4, 2000, [EMAIL PROTECTED] (Greg A. Woods) wrote:
> [ On , September 3, 2000 at 16:44:05 (-0300), Alexandre Oliva wrote: ]
>> Subject: Re: HTML format documentation
>>
>> There's no need to introduce knowledge about particular systems in
>> autoconf:
[ On , September 3, 2000 at 16:44:05 (-0300), Alexandre Oliva wrote: ]
> Subject: Re: HTML format documentation
>
> There's no need to introduce knowledge about particular systems in
> autoconf: each system can take care of the issue on its own.
Ah, no, that's not even re
On Fri, Sep 01, 2000 at 09:38:28PM -0600, Richard Stallman wrote:
: 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
On Sep 3, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> 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,
[ On Saturday, September 2, 2000 at 22:57:04 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> Developers can make all sorts of mistakes. The mistakes just have to
> be fixed. Developers who ignore or misunderstand the rules for what
> files should g
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.
[ On Saturday, September 2, 2000 at 12:03:05 (-0400), Steve Robbins wrote: ]
> Subject: Re: HTML format documentation
>
> Would you be happier if the option was called just --confdir ?
yes, that would be OK too (and of course the make variable should
be changed
On Fri, 1 Sep 2000, Greg A. Woods wrote:
> [ On , September 1, 2000 at 09:30:27 (-0400), Paul D. Smith wrote: ]
> > Subject: Re: HTML format documentation
> >
> > I say just leave the sysconfdir default as ${prefix}/etc (or whatever).
>
> The problem with that is stil
On Sep 2, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> 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
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
Paul D Smith <[EMAIL PROTECTED]> writes:
> %% [EMAIL PROTECTED] (Greg A. Woods) writes:
> gaw> This nonsense of giving the user ultimate and complete control
> gaw> over where each and every individual class of files, while at the
> gaw> same time not learning and honouring platform specifi
On Sep 1, 2000, [EMAIL PROTECTED] (Greg A. Woods) wrote:
> [ On , September 1, 2000 at 09:30:27 (-0400), Paul D. Smith wrote: ]
>> Subject: Re: HTML format documentation
>>
>> I say just leave the sysconfdir default as ${prefix}/etc (or whatever).
> The problem
[ On , September 1, 2000 at 11:13:04 (-0400), Paul D. Smith wrote: ]
> Subject: Re: HTML format documentation
>
> No. This is exactly the right way to do it.
>
> Autoconf should provide a well-defined set of directories, each with a
> well-defined purpose/policy, and each wi
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On , September 1, 2000 at 09:30:27 (-0400), Paul D. Smith wrote: ]
> > Subject: Re: HTML format documentation
> >
> > I say just leave the sysconfdir default as ${prefix}/etc (or whatever).
>
> The pr
[ On , September 1, 2000 at 09:30:27 (-0400), Paul D. Smith wrote: ]
> Subject: Re: HTML format documentation
>
> I say just leave the sysconfdir default as ${prefix}/etc (or whatever).
The problem with that is still that $(prefix)/etc is not usually the
systems' configuration
%% [EMAIL PROTECTED] (Greg A. Woods) writes:
gaw> This nonsense of giving the user ultimate and complete control
gaw> over where each and every individual class of files, while at the
gaw> same time not learning and honouring platform specific policies
gaw> for the defaults (i.e. choosing
[ On Thursday, August 31, 2000 at 19:20:47 (+0200), Peter Eisentraut wrote: ]
> Subject: Re: HTML format documentation
>
> Richard Stallman writes:
>
> > If prefix is `/usr', use `/etc'.
> > Otherwise, use $(prefix)/config.
>
> I hope not. Hard-c
%% Alex Hornby <[EMAIL PROTECTED]> writes:
ah> Richard Stallman writes:
>> I think we need to ask the community of developers what they would
>> think of this change. It sounds good, but it could have pitfalls
>> we have not thought of.
>>
>> Would someone like to do that?
ah> I
1 - 100 of 144 matches
Mail list logo
