be a
general-purpose macro, and it's also not part of the published
interface. I don't know whether it would be easier to modify the
existing internal macros or just start from scratch, but I guess it
doesn't matter as long as the result is the same. :)
Anyway, I'd appreciate a
Anyway, if we could introduce something like this, it would make it
much easier for people to share autoconf macros, which IMHO would make
autoconf a much more useful tool. Please let me know what you think.
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
module" in order to use it? This isn't
necessary because perl knows to look in its site_perl directory, which
makes it much more convenient.
On Wed May 15 20:38 2002 -0400, Thomas Dickey wrote:
> On Wed, May 15, 2002 at 05:38:40PM -0500, Mark D. Roth wrote:
> > "${pref
le, just like aclocal does. That way you still
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 it be ac
done in one step.
It would also be nice if the autoconf installation let you override
the path of the site macro directory, but that's a fairly minor
detail.
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
he autoconf installer or autoconf user says so. If
> the feature proves to be popular, we can always change this default.
As I mentioned above, I think it would be better for it to check the
site macro directory by default, but I can live with it being an
option if that's what everyon
to be distributed with the package, so people can modify
configure.ac without needing to obtain the macros seperately.
* For those that do want to distribute macros seperately, the site
macro directory provides a simple, convenient way for autoconf to
find locally installed macros.
* Package-specific macros take precedence over site macros.
Comments...?
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
ros seperately.
* For those that do want to distribute macros seperately, the site
macro directory provides a simple, convenient way for autoconf to
find locally installed macros.
* Package-specific macros take precedence over site macros.
Other comments...?
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
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 PROTE
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 packa
On Fri May 17 09:55 2002 -0700, [EMAIL PROTECTED] wrote:
> ==> "mdr" == Mark D Roth <[EMAIL PROTECTED]> writes:
>
> mdr> To address this problem, I'd like to see the following two
> mdr> macros added to autoconf:
>
> mdr>
is with any of the macros that I've
written. Can you give me a concrete example of this? I would think
that this problem could be avoided by proper quoting and using
AC_REQUIRE or AC_BEFORE.
Anyway, I hope this clarifies what I'm proposing. I'm sorry for the
confusion.
As always, all comments and feedback would be appreciated.
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
doesn't eliminate the need for a preset site macro directory
(just as $PERL5LIB doesn't eliminate the need for a site_perl
directory). Bear in mind that one of the main goals of having a site
macro directory is to allow people to package up autoconf macros and
distribute them seper
to support all of them.
If I had to choose between the two macros, I'd rather have an
AC_LOG_MSG macro, because that's the part that I'm currently lacking
an interface for. If I have AC_LOG_MSG, I can roll my own
AC_RUN_COMMAND, but without AC_LOG_MSG, I have no supported interfa
way for autoconf to
find locally installed macros.
* Package-specific macros take precedence over site macros.
Other comments...?
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
s for the info!
On Tue May 21 19:07 2002 -0500, Mark D. Roth wrote:
> Here's what it looks like now:
>
> * 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 gi
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
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.
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
rent directory", I meant "the value obtained
from getcwd(3)", which has nothing to do with where any particular
file may be located. I probably should have been more specific; sorry
for the confusion.
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
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. th
`-I' option.
2. The current working directory ($top_srcdir).
3. Directories specified in the $AC_MACRO_PATH environment variable
(if set).
4. The system-wide site macro directory (set when autoconf is
installed).
Please let me know what you think.
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
:
* add support for $AC_MACRO_PATH
* add configure option for setting system-wide site macro directory
I think this proposal solves the problem nicely, but I'm not totally
wed to it. If you have an alternate solution, I'd love to hear it.
However, I don't think it's reaso
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
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 th
sounds good!
Great. Please let me know what you think of the patch. Thanks!
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
jects/encap-src/psg/sparc-solaris8/dummy-0.1
$ cd .
$ pwd
/usr/local/src/dummy-0.1
$ /bin/pwd
/projects/encap-src/psg/sparc-solaris8/dummy-0.1
This is obviously something we need to work around, but I'm just not
sure what the best way is to fix it. The only thing I can think of is
to use "`/bin/pwd`" instead of "." for $ac_dir, but I'm not sure if
that would break anything else.
Any suggestions?
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
ksh
Is this what you're seeing as well? If your config.status were being
created using /bin/sh, then that might explain why you're not seeing
the problem...
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
ll back on
> /bin/pwd only if the current method fails? That way, only the poor
> ksh users will be stuck with the problems of ugly names and/or
> /bin/pwd failing.
Sounds reasonable. Please look over the attached patch and let me
know what you think. If it looks good, I'll comm
this.
> I also looked at POSIX 1003.1-2001, and discovered that it _requires_
> the ksh93 behavior.
>
> So it appears to me that the "proper" fix is to try "cd -P DIR" first,
> and to fall back on plain "cd DIR" if that doesn't work.
Sounds go
other than directories.
This is a really good idea. Adding this macro would kill two birds
with one stone: it would provide a way for user macros to handle the
problem, and it would also allow us to easily fix autoconf to do the
right thing.
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
31 matches
Mail list logo
