> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 26 May 2002 12:20:00 +0200
>
> If the problem is wrt -I, I'm fine with renaming it -i.
Yes, that would be an improvement.
Presumably -I would append the path names, but -i would prepend them,
so you could mix -i and -I with predictable results.
On Sun May 26 12:15 2002 +0200, Akim Demaille wrote:
> | * autoconf's search path should be:
> | 1. any directories specified in `-I' options
> | 2. the current directory (i.e., $top_srcdir)
> | 3. the directories specified in $AC_MACRO_PATH (if set)
> | 4. the system-wid
On Sun May 26 12:08 2002 +0200, Akim Demaille wrote:
> I'd like to find a means to preserve the simplicity of autom4te and
> autom4te.cfg. Maybe an additional -I like option would suffice. The
FYI, that's exactly how my patch solves this problem. Please let me
know what you think.
--
Mark D.
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> From: Akim Demaille <[EMAIL PROTECTED]> Date: 24 May 2002 12:35:53
>> +0200
>> | Every other tool that I know of that accepts a `-I' option
>> (including | gcc, GNU make, GNU m4, and perl) prepends the
>> arguments to the search | path i
| I've proposed a solution that would solve this problem without
| removing any flexibility. Just to keep everyone on the same page, my
| current proposal is:
|
| * autoconf's search path should be:
| 1. any directories specified in `-I' options
| 2. the current directory (i.e., $
> On Fri May 24 12:35 2002 +0200, Akim Demaille wrote:
> > | While working on this, I noticed that the current autom4te code
> > | reverses the order of the `-I' options before passing them to m4. The
> > | documentation says:
> > |
> > | `--include=DIR'
> > | `-I DIR'
> > |Also loo
On Wed May 22 21:40 2002 -0500, Mark D. Roth wrote:
> On Wed May 22 15:50 2002 -0700, Paul Eggert wrote:
> > My own reaction is positive, but I would suggest that you write up the
> > proposal, as a proposed patch to the manual. (Often the documentation
> > is the hardest to write, so perhaps it'
Mark D Roth <[EMAIL PROTECTED]> writes:
> My thought was that this wasn't necessary, since you can read files in
> subdirectories of any directory in the search path by specifying a
> relative path. For example, you could say `m4_include([m4/foo.m4])' to
> read a file in the `m4' subdirectory.
Peter Eisentraut wrote:
> I'm not sure this is necessary. No package is strictly speaking
> self-contained. If, say, my package depends on GTK, then I rely on GTK
> being installed somewhere before I start building. And therefore it could
> also be reasonable to assume that the gtk.m4 file wit
Akim Demaille writes:
> My own idea is: the package *must* be self contained, included the src
> tree. Which means that, contrary to aclocal which has dependencies
> outside the src tree, autoreconf --install was meant to fetch in
> /usr/local/aclocal etc. the relevant files, and to install a co
> From: "Mark D. Roth" <[EMAIL PROTECTED]>
> Date: Fri, 24 May 2002 09:58:56 -0500
>
> * add support for $AC_MACRO_PATH
> * add configure option for setting system-wide site macro directory
I assume that if that configure option is not used, then there would
not be a system-wide site macro d
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 24 May 2002 12:35:53 +0200
> | Every other tool that I know of that accepts a `-I' option (including
> | gcc, GNU make, GNU m4, and perl) prepends the arguments to the search
> | path in the order specified. As a result, I was extremely surprised
On Fri May 24 12:14 2002 +0200, Akim Demaille wrote:
> I'm really against AC_SITE_INCLUDE, as per the GCS, a package must be
> self-contained (from the sources point of view). Nevertheless,
> autoreconf --install --symlink is to provide the same effect. It just
> bring your SITE macros into the
On Fri May 24 12:35 2002 +0200, Akim Demaille wrote:
> | While working on this, I noticed that the current autom4te code
> | reverses the order of the `-I' options before passing them to m4. The
> | documentation says:
> |
> | `--include=DIR'
> | `-I DIR'
> |Also look for input files
On Thu May 23 15:15 2002 -0700, Russ Allbery wrote:
> Mark D Roth <[EMAIL PROTECTED]> writes:
>
> > So, here's my new proposal:
>
> > * autoconf's search path should be:
> > 1. the current directory (i.e., $top_srcdir)
> > 2. the directories specified in $AC_MACRO_PATH (if set)
> >
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> You might want to dig into the Autoconf archives. For instance,
Akim> start with
Akim>
Akim> http://mail.gnu.org/pipermail/autoconf-patches/2000-July/005546.html
Akim> and dig around.
Actually, that July seems to contain much of
> "Mark" == Mark D Roth <[EMAIL PROTECTED]> writes:
Mark> The current behavior seems to date back to revision 1.42 of
Mark> bin/autom4te.in from September 5th, 2001. Can someone explain
Mark> to me why this change was made? Thanks!
To understand how autom4te works, have a look at autom4te.
| On Wed May 22 21:40 2002 -0500, Mark D. Roth wrote:
| > On Wed May 22 15:50 2002 -0700, Paul Eggert wrote:
| > > My own reaction is positive, but I would suggest that you write up the
| > > proposal, as a proposed patch to the manual. (Often the documentation
| > > is the hardest to write, so
> "Mark" == Mark D Roth <[EMAIL PROTECTED]> writes:
Mark> On Wed May 22 10:36 2002 -0500, Mark D. Roth wrote:
>> Barring any further input from anyone, it seems like we've reached
>> a consensus on this proposal. The final version is included below.
Mark> Actually, I just realized that usin
> "Mark" == Mark D Roth <[EMAIL PROTECTED]> writes:
Mark> First, autoconf will be modified to read all of the m4 files in
Mark> the `ac-package' subdirectory. Just as with the aclocal.m4
Mark> file, these files will be read automatically; no AC_INCLUDE
Mark> macro will be necessary to read i
> "Mark" == Mark D Roth <[EMAIL PROTECTED]> writes:
>> But that's what the m4 subdirectory is for, with aclocal. This is
>> replicating function, and it's confusing. Why not just call it
>> 'm4', as before? People using aclocal can continue to use m4/*.m4;
>> people using Autoconf with you
> "Mark" == Mark D Roth <[EMAIL PROTECTED]> writes:
Mark> In any event, I'll rename my proposed macro to AC_SITE_INCLUDE
Mark> to avoid confusion.
I'm really against AC_SITE_INCLUDE, as per the GCS, a package must be
self-contained (from the sources point of view). Nevertheless,
autoreconf
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> From: "Mark D. Roth" <[EMAIL PROTECTED]> Date: Thu, 16 May 2002
>> 19:19:56 -0500
>>
>> * autoconf will have an AC_INCLUDE macro that causes it to read a
>> specific file from the site macro directory.
Paul> Autoconf used to have AC_INC
Mark D Roth <[EMAIL PROTECTED]> writes:
> So, here's my new proposal:
> * autoconf's search path should be:
> 1. the current directory (i.e., $top_srcdir)
> 2. the directories specified in $AC_MACRO_PATH (if set)
> 3. the system-wide site macro directory (set at autoconf inst
On Thu May 23 01:35 2002 -0700, Paul Eggert wrote:
> The "current directory" from a particular file's point of view is the
> directory that the file is in, and this is not necessarily $topdir.
> (This is the problem that I was thinking of.)
Ah, OK. When I said "current directory", I meant "the v
> From: "Mark D. Roth" <[EMAIL PROTECTED]>
> Date: Wed, 22 May 2002 21:40:56 -0500
>
> I was under the impression that autoconf needed to be invoked in the
> top source directory, in which case the current directory will
> always be $top_srcdir.
The "current directory" from a particular file's p
On Wed May 22 21:40 2002 -0500, Mark D. Roth wrote:
> On Wed May 22 15:50 2002 -0700, Paul Eggert wrote:
> > My own reaction is positive, but I would suggest that you write up the
> > proposal, as a proposed patch to the manual. (Often the documentation
> > is the hardest to write, so perhaps it'
On Wed May 22 15:50 2002 -0700, Paul Eggert wrote:
> On Wed, 22 May 2002 13:56:33 -0500, Mark D. Roth wrote:
> > * autoconf's search path should be:
> > 1. the current directory (i.e., $top_srcdir)
>
> But the current directory is not top_srcdir in all cases.
> E.g. an include file in one
> From: "Mark D. Roth" <[EMAIL PROTECTED]>
> Date: Wed, 22 May 2002 13:56:33 -0500
>
> * autoconf's search path should be:
> 1. the current directory (i.e., $top_srcdir)
But the current directory is not top_srcdir in all cases.
E.g. an include file in one directory might include another.
On Wed May 22 10:36 2002 -0500, Mark D. Roth wrote:
> Barring any further input from anyone, it seems like we've reached a
> consensus on this proposal. The final version is included below.
Actually, I just realized that using a single include macro to handle
both the local files and the system-
Barring any further input from anyone, it seems like we've reached a
consensus on this proposal. The final version is included below.
Paul or Akim, can one of you tell me how to procede with this? Should
I submit a patch, or would you prefer to implement these changes
yourselves?
Thanks for th
On Tue May 21 10:52 2002 -0500, Kenneth Pronovici wrote:
> I think it would work better to choose a scheme that would let a given
> autoconf user specify some list of site-wide directories for their
> own use, with the default being to use just the /usr/local/whatever
> directory specified at inst
> > Part two, designating a single directory as the site directory is not
> > going to be liked by everybody. If Autoconf is installed as part of "the
> > system" under /usr, many people won't like to put AC files belonging to
> > "locally" installed packages somewhere under /usr/share or whereev
On Sun May 19 17:14 2002 +0200, Peter Eisentraut wrote:
> Part one, automatically reading all files that are named a particular way
> is not a strategy that is commonly followed by other tools (e.g, the C
> compiler automatically including all *.h files in the current directory).
> Normally you ca
Mark D. Roth writes:
> First, autoconf will be modified to read all of the m4 files in the
> `ac-package' subdirectory.
> Second, an AC_SITE_INCLUDE macro will be added to allow individual m4
> files to be read from the system's site macro directory.
> If it helps, think of these two modificati
On Sat May 18 14:56 2002 -0700, Paul Eggert wrote:
> Yes, but the cure of having two subdirectories is worse than the
> disease. It will complicate the explanations to users, and will
> complicate source directory structures, and will lead to lots of
> confusion.
>
> I think it would be better t
> From: "Mark D. Roth" <[EMAIL PROTECTED]>
> Date: Sat, 18 May 2002 09:11:55 -0500
>
> The main reason for giving it a different name is that we want to
> avoid conflicts between autoconf and aclocal. If autoconf reads the
> files in the subdirectory by default, and aclocal also reads them to
>
On Fri May 17 17:26 2002 -0700, Paul Eggert wrote:
> On Thu, 16 May 2002 21:05:37 -0500, Mark D. Roth wrote:
> > Instead of a local cache, let's create a subdirectory called
> > `ac-package' that includes macros that the developer wants to ship
> > with the package.
>
> But that's what the m4 sub
> From: "Mark D. Roth" <[EMAIL PROTECTED]>
> Date: Thu, 16 May 2002 21:05:37 -0500
>
> Instead of a local cache, let's create a subdirectory called
> `ac-package' that includes macros that the developer wants to ship
> with the package.
But that's what the m4 subdirectory is for, with aclocal.
What about acinclude.m4, or am I missing something?
H
On Thu May 16 22:08 2002 -0400, Harlan Stenn wrote:
> What about acinclude.m4, or am I missing something?
If I understand everything correctly, autoconf doesn't read
acinclude.m4, but aclocal does. Neither of those things would be
changing.
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.n
On Thu May 16 18:29 2002 -0700, Paul Eggert wrote:
> > * autoconf will have an AC_INCLUDE macro that causes it to read a
> > specific file from the site macro directory.
>
> Autoconf used to have AC_INCLUDE, but it got removed in 2.49a.
> Apparently, it got replaced with autoreconf --instal
> From: "Mark D. Roth" <[EMAIL PROTECTED]>
> Date: Thu, 16 May 2002 19:19:56 -0500
>
> * autoconf will have an AC_INCLUDE macro that causes it to read a
> specific file from the site macro directory.
Autoconf used to have AC_INCLUDE, but it got removed in 2.49a.
Apparently, it got replaced
> Date: Thu, 16 May 2002 16:37:49 -0700
> From: Bruce Korb <[EMAIL PROTECTED]>
> Am I alone in thinking that there are serious design issues
> that would be good to resolve before messing with all these
> implementation methods?
No, I share these concerns. However, I don't know of anyone who ha
On Thu May 16 16:07 2002 -0700, Paul Eggert wrote:
> But the site macro directory contains files. Will you ignore the file
> structure, and effectively treat the directory's files as one huge
> file that is concatenated? I don't see how this would scale.
My understanding was that this is what a
> From: "Mark D. Roth" <[EMAIL PROTECTED]>
> Date: Thu, 16 May 2002 14:36:37 -0500
>
> * autoconf will continue to treat aclocal.m4 as a user-supplied
> input file, since there will probably always be a call for macros
> that are specific to a given package and not worth sharing.
>
>
"Mark D. Roth" wrote:
>
>
> Does this work for everyone?
>
Works for me.
> > Also, I would say that for now there should not be a site macro
> > directory unless the autoconf installer or autoconf user says so. If
> > the feature proves to be popular, we can always change this default.
>
> A
On Thu May 16 11:31 2002 -0700, Paul Eggert wrote:
> Personally, I dislike site directories since
> they make it a hassle to move my stuff from one site to another.
> However, I wouldn't object to having a configure-time option for
> building autoconf, for people who like to have site directories.
Es schrieb Paul Eggert:
>
> > From: "Mark D. Roth" <[EMAIL PROTECTED]>
> > Date: Thu, 16 May 2002 12:28:27 -0500
> >
> > That's fine, as long as it gets invoked automatically when you invoke
> > autoconf. It should all get done in one step.
>
> Personally, I dislike site directories since
> the
> From: "Mark D. Roth" <[EMAIL PROTECTED]>
> Date: Thu, 16 May 2002 12:28:27 -0500
>
> That's fine, as long as it gets invoked automatically when you invoke
> autoconf. It should all get done in one step.
Personally, I dislike site directories since
they make it a hassle to move my stuff from o
On Thu, May 16, 2002 at 12:28:27PM -0500, Mark D. Roth wrote:
> On Thu May 16 17:55 2002 +0100, Sam Clegg wrote:
> > Sounds like what you want is very similar to aclocal. Why not instead
> > try to get aclocal shipped with autoconf instead of automake?
>
> That's fine, as long as it gets invoked
On Thu May 16 17:55 2002 +0100, Sam Clegg wrote:
> Sounds like what you want is very similar to aclocal. Why not instead
> try to get aclocal shipped with autoconf instead of automake?
That's fine, as long as it gets invoked automatically when you invoke
autoconf. It should all get done in one
Es schrieb "Mark D. Roth":
>
> On Thu May 16 05:59 2002 -0400, Thomas E. Dickey wrote:
> > aclocal has good intentions, poor design.
>
> I don't really understand why everyone says that like there's nothing
> we can do about it. If the design is poor and inconvenient, let's fix
> it! That is w
On Thu, May 16, 2002 at 09:28:05AM -0500, Mark D. Roth wrote:
> I'm not sure that I agree that having a site macro directory makes it
> any more likely for developers to screw things up. However, even if
> that is the case, we can have autoconf cache any macros that get used
> in the aclocal.m4 f
On Thu, May 16, 2002 at 03:25:07AM -0400, Allan Clark wrote:
> "Mark D. Roth" wrote:
> >
> > On Wed May 15 17:21 2002 -0700, Paul Eggert wrote:
> > > I use Automake's "aclocal" for this. It generates aclocal.m4
> > > automatically from m4/*.m4. In my case, the m4/*.m4 files are often
> > > link
On Thu, 16 May 2002, Mark D. Roth wrote:
> On Thu May 16 05:59 2002 -0400, Thomas E. Dickey wrote:
>
> I'm not sure that I agree that having a site macro directory makes it
> any more likely for developers to screw things up. However, even if
> that is the case, we can have autoconf cache any ma
On Thu, 16 May 2002, Mark D. Roth wrote:
> get a copy of all of the necessary macros as part of the distributed
> package, but it happens automatically and without the need to install
> a seperate package. Would that address this objection?
>
>
> If I submit a patch to add this behavior, would i
On Thu May 16 05:59 2002 -0400, Thomas E. Dickey wrote:
> aclocal has good intentions, poor design.
I don't really understand why everyone says that like there's nothing
we can do about it. If the design is poor and inconvenient, let's fix
it! That is why it's called "software", after all. :)
On Wed, 15 May 2002, Mark D. Roth wrote:
> > I think "aclocal" pretty much does what you want.
> > E.g., "aclocal --print-ac-dir", and "aclocal -I DIR".
aclocal has good intentions, poor design.
> It doesn't really make sense to me that I should need to install a
> seperate package just to be a
On Wed, May 15, 2002 at 11:03:18PM -0500, Mark D. Roth wrote:
> On Wed May 15 17:21 2002 -0700, Paul Eggert wrote:
> > I use Automake's "aclocal" for this. It generates aclocal.m4
> > automatically from m4/*.m4. In my case, the m4/*.m4 files are often
> > links to the "canonical" versions.
>
>
"Mark D. Roth" wrote:
>
> On Wed May 15 17:21 2002 -0700, Paul Eggert wrote:
> > I use Automake's "aclocal" for this. It generates aclocal.m4
> > automatically from m4/*.m4. In my case, the m4/*.m4 files are often
> > links to the "canonical" versions.
>
> Unfortunately, that won't work for me
On Wed May 15 17:21 2002 -0700, Paul Eggert wrote:
> I use Automake's "aclocal" for this. It generates aclocal.m4
> automatically from m4/*.m4. In my case, the m4/*.m4 files are often
> links to the "canonical" versions.
Unfortunately, that won't work for me, since I use autoconf but not
automa
On Wed, May 15, 2002 at 05:38:40PM -0500, Mark D. Roth wrote:
> I propose that we modify autoconf to have a system-wide site macro
> directory (analogous to emacs's site-lisp directory or perl's
I seem to recall this topic coming up more than once.
> "${prefix}/share/autoconf/site_macros"). If
> From: "Mark D. Roth" <[EMAIL PROTECTED]>
> Date: Wed, 15 May 2002 17:38:40 -0500
>
> Currently, I need to copy each macro I maintain into the aclocal.m4
> file of each package that needs to use the macro.
I use Automake's "aclocal" for this. It generates aclocal.m4
automatically from m4/*.m4.
64 matches
Mail list logo
