Thank You for the detailed answer :-)
-V.
On Sat, Feb 1, 2020 at 9:58 PM Russ Allbery wrote:
> Vincent Blondel writes:
>
> > Encounter a strange behaviour with autoconf.
> > I do not understand why all the compiled *.o files are prefixed with
> > target-xxx.o.
>
> > Below an example ... have no
Vincent Blondel writes:
> Encounter a strange behaviour with autoconf.
> I do not understand why all the compiled *.o files are prefixed with
> target-xxx.o.
> Below an example ... have no progname yet for my executable hence let's
> call it main for now ...
> bin_PROGRAMS = main
> main_SOURCES
Hello,
Vincent Blondel (2020/02/01 17:10 +0100):
> Hello,
>
> Encounter a strange behaviour with autoconf.
> I do not understand why all the compiled *.o files are prefixed with
> target-xxx.o.
>
> Below an example ... have no progname yet for my executable hence let's
> call it main for now ...
>
Hello,
Encounter a strange behaviour with autoconf.
I do not understand why all the compiled *.o files are prefixed with
target-xxx.o.
Below an example ... have no progname yet for my executable hence let's
call it main for now ...
bin_PROGRAMS = main
main_SOURCES = obj1.cc obj2.cc
Executable
Hi,
CLISP interface to PARI is configured with the configure.in containing
AC_LIB_LINKFLAGS([pari]).
The build process also requires the Makefile to know where the datadir
of pari is located. To this end, Makefile.in has
--8<---cut here---start->8---
On 02/10/2014 05:05 PM, Adam Jiang wrote:
Actually, the problem could be resolved by
AM_CFLAGS = -DPKGDATA=$(pkgdata)
just like the manual described. Paths of all files in $(pkgdata) could be
referred with PKGDATA + basename.
AM_CFLAGS => automake
You are off-topic for this list
__
Autoconf could help to generate configure script which accepts an option
> > called --prefix in general. In this way, users could specific a path
> where
> > programs/data installed.
>
> ALL configure scripts generated by autoconf accept --prefix.
>
> It sounds like
On 02/09/2014 05:17 AM, Adam Jiang wrote:
> Autoconf could help to generate configure script which accepts an option
> called --prefix in general. In this way, users could specific a path where
> programs/data installed.
ALL configure scripts generated by autoconf accept --prefix.
It so
On 02/09/2014 10:17 PM, Adam Jiang wrote:
Autoconf could help to generate configure script which accepts an option
called --prefix in general. In this way, users could specific a path where
programs/data installed.
In my program, I'd like to refer the location where data files are
installe
On 02/09/2014 01:17 PM, Adam Jiang wrote:
Autoconf could help to generate configure script which accepts an option
called --prefix in general. In this way, users could specific a path where
programs/data installed.
In my program, I'd like to refer the location where data files are
installe
Autoconf could help to generate configure script which accepts an option
called --prefix in general. In this way, users could specific a path where
programs/data installed.
In my program, I'd like to refer the location where data files are
installed. In plain Makefile, it could be done like
* Jason Sewall wrote on Sun, Apr 25, 2010 at 07:16:25PM CEST:
> Ralf Wildenhues gmx.de> writes:
> > $ac_top_srcdir, as documented in "info Autoconf 'Configuration Actions'".
> > Since configure is always run the top build directory, it should suffice
> > to use $srcdir though.
>
> Well, perhaps I
Ralf Wildenhues gmx.de> writes:
> $ac_top_srcdir, as documented in "info Autoconf 'Configuration Actions'".
> Since configure is always run the top build directory, it should suffice
> to use $srcdir though.
Well, perhaps I understand less of autoconf than I thought I did. I
tried to put GIT_VER
* Jason Sewall wrote on Sun, Apr 25, 2010 at 05:21:25PM CEST:
> Russ Allbery writes:
> > > GIT_VERSION=`./GIT-VERSION-GEN`
> >
> > > Obviously, that './' in there doesn't work if I try to configure outside
> > > my source directory. What variabl
't work if I try to configure outside
> > my source directory. What variable do I need add as prefix to that path
> > to let builds outside the source tree find that script?
>
> If that reference is in a Makefile.am or something similar, you want
> either $(abs_top_srcdir
EN`
> Obviously, that './' in there doesn't work if I try to configure outside
> my source directory. What variable do I need add as prefix to that path
> to let builds outside the source tree find that script?
If that reference is in a Makefile.am or something similar, you w
doesn't work if I try to configure
outside my source directory. What variable do I need add as prefix to
that path to let builds outside the source tree find that script?
Cheers,
Jason
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Hi Ralf,
Thanks for the swift reply!
I feel sheepish now since I read right past that configure.gnu trick
in the autoconf manual entry for AC_CONFIG_SUBDIRS. I gave it a
whirl, calling the normal generated ./configure from ./configure.gnu:
./configure --prefix=${prefix}/hyrax_icu
Hi Ralf, Michael,
Ralf Corsepius wrote:
c) There is a hidden feature in autoconf's AC_CONFIG_SUBDIR (cf.
_AC_CONFIG_SUBDIRS in /usr/share/autoconf/status.m4 for details):
If a toplevel configure finds a file called "configure.gnu" inside of
a CONFIG_SUBDIR, it invokes "configure.gnu" instead of
On 01/28/2010 05:29 PM, Michael Johnson wrote:
Hello autoconf gurus,
I am wondering if there is a way to modify the prefix passed down in a
recursive autoconf which uses the AC_CONFIG_SUBDIRS to recurse into
subprojects.
Situation: I have project A which has two subprojects B and C (which
also
Hello autoconf gurus,
I am wondering if there is a way to modify the prefix passed down in a
recursive autoconf which uses the AC_CONFIG_SUBDIRS to recurse into
subprojects.
Situation: I have project A which has two subprojects B and C (which
also contain others subprojects, and A may
In a ./configure script I am working on
I make use of the idiom: AC_RUN_IFELSE( [ some code ], [ success ], [
failure ] )
The problem is, the CFLAGS and LDFLAGS at that point contain:
CFLAGS="-I$includedir"
And LDFLAGS="-L$libdir -Wl,-rpath,$libdir"
Which - is correct
however, whe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Fritz Code on 8/25/2008 12:00 AM:
>
> But the build-system I'm using at the moment uses prefix to specify the
> location of the toolchain on the host.
> E.g. --prefix /opt/devel/arm7/
Correct - --prefix is for
Hi
well as far as I know the prefix parameter of the configure script defines
the folder where the program which gets build is supposed to be installed.
So I mean where it is supposed to run and execute.
E.g. we pass a prefix like /home/fritz/newprog then the program gets
installed to that folder
I'm doing some contracting and for various reasons, my
client has been using a customized prefix and program-prefix
to carefully isolate their hacked binaries and libraries
from other versions for some opensource packages.
I started reading the autoconf/autotools documentation
expecting the
ld still refer to other
> variables. For example, a recent addition to autoconf is the datarootdir
> variable, and datadir is now defined in terms of datarootdir, which in
> turn is defined in terms of prefix. A two level expansion of datadir will
> no loger lead to a fully expanded v
Stefano Sabatini <[EMAIL PROTECTED]> writes:
> Follow a possible implementation of this suggestion:
>
> to put in the input Perl script "script.in" something as:
> my $prefix="@prefix@";
> ...
> my $system_config_file= "@SYSCONF_DIR@/script.conf&q
pendant paths.
> >
> > Since I don't want to hardcode them, I created a "script.in" file, which
> > contains a line with:
> >
> > my $system_config_file= "@SYSCONF_DIR@/script.conf";
> >
> > and placed this snippet in configure.ac:
&g
th:
>
> my $system_config_file= "@SYSCONF_DIR@/script.conf";
>
> and placed this snippet in configure.ac:
>
> dnl $sysconfdir contains "${prefix}/etc, so I have to
> dnl eval it another time
> eval "eval SYSCONF_DIR=$sysconfdir"
>
> AC_SUBST(SYSCO
.conf";
and placed this snippet in configure.ac:
dnl $sysconfdir contains "${prefix}/etc, so I have to
dnl eval it another time
eval "eval SYSCONF_DIR=$sysconfdir"
AC_SUBST(SYSCONF_DIR)
AC_CONFIG_FILES(script)
This works mainly as expected, but in the script
I would like to be able to echo the users choice for
--prefix
while the configure script executes.
For example, the configure script documented in
http://www.coin-or.org/CppAD/Doc/installunix.htm
currently starts with the following output
configure: Begin Checking Command Line
Hello Brad,
thank you for your concise description of the problem.
On Sun, Jan 01, 2006 at 07:29:22AM -0800, Brad Bell wrote:
>configure: Begin Checking Command Line arguments ***
>checking --prefix ... your choice can't be reported here (autoconf
&
On Friday 02 December 2005 5:01 pm, Andreas Schwab wrote:
> Keith Marshall <[EMAIL PROTECTED]> writes:
> > BTW, I don't think ac_default_prefix is officially documented
>
> But AC_PREFIX_DEFAULT is.
>
> -- Macro: AC_PREFIX_DEFAULT (PREFIX)
> Set the de
Keith Marshall <[EMAIL PROTECTED]> writes:
> BTW, I don't think ac_default_prefix is officially documented
But AC_PREFIX_DEFAULT is.
-- Macro: AC_PREFIX_DEFAULT (PREFIX)
Set the default installation prefix to PREFIX instead of
`/usr/local'.
Andreas.
--
Andrea
On Fri, 2 Dec 2005, Keith Marshall wrote:
BTW, I don't think ac_default_prefix is officially documented -- its use can
be discovered by inspecting any generated configure script. Do beware that,
as an undocumented feature, it may not be supported by future autoconf
versions.
Furthermore, even
On Friday 02 December 2005 9:14 am, Roesner Thomas wrote:
> Thank you for your hint, "ac_default_prefix=`pwd`" works fine.
> I had the same in with uppercase, and it did not work.
No. It's just an ordinary Bourne shell variable assignment, so is case
sensitive. Most autoconf local variable name
5 22:52
An: Roesner Thomas; autoconf@gnu.org
Betreff: Re: AW: prefix
A further thought:
On Thursday 01 December 2005 1:54 pm, I wrote:
> On Thursday 01 December 2005 6:40 am, Roesner Thomas wrote:
> > thank you for the replie, "make DESTDIR=`pwd` install" works fine, but
> >
I´d
> > prefer setting it within the configure.in or Makefile.am.
>
> You _could_ just say `prefix=""', in configure.in -- today, you should
> really be using configure.ac, with autoconf 2.59 -- just before the
> AC_OUTPUT.
>
> However, you really should not
On Thursday 01 December 2005 6:40 am, Roesner Thomas wrote:
> thank you for the replie, "make DESTDIR=`pwd` install" works fine, but i´d
> like to omit the naming of the installpath in all commands. I´d prefer
> setting it within the configure.in or Makefile.am.
You _coul
on: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Baurzhan
Ismagulov
Gesendet: Mittwoch, 30. November 2005 18:14
An: autoconf@gnu.org
Betreff: Re: prefix
Hello Thomas,
On Tue, Nov 29, 2005 at 01:13:41PM +0100, Roesner Thomas wrote:
> i want to configure my package without setting the --
Baurzhan Ismagulov wrote:
> Roesner Thomas wrote:
> > i want to configure my package without setting the --prefix option. By
> > default "make install" tries to copy libs and binaries to /usr/lib or
> > /usr/bin, but I need the files copied to ./bin and ./lib.
&g
Hello Thomas,
On Tue, Nov 29, 2005 at 01:13:41PM +0100, Roesner Thomas wrote:
> i want to configure my package without setting the --prefix option. By
> default "make install" tries to copy libs and binaries to /usr/lib or
> /usr/bin, but I need the files copied to ./bin
Dear all,
i want to configure my package without setting the --prefix option. By
default "make install" tries to copy libs and binaries to /usr/lib or
/usr/bin, but I need the files copied to ./bin and ./lib.
Can anybody tell me wich variable must be set to `pwd` within the
configure
Hello,
On Mon, May 23, 2005 at 12:55:42PM +0200, Linus Walleij wrote:
> The manipulation of program_transform_name is necessary because program
> prefix is rewritten into a transformation regexp before any commands in
> the configure.ac/.in file are executed.
this is not exactly t
In february there was a mail to the list asking how to set a default
program-prefix, with the same effect as giving it to the command line
using ./configure --program-prefix=foo.
I had to achieve this and it turns out the following hack in a
configure.ac/.in file will do:
# This can be
Hi,
On Thu, Feb 17, 2005 at 06:18:14PM +0100, JRBCAST wrote:
> My question is: How can I set a default progra-prefix [...]
> ./configure --program-prefix=foopref_
case $program_prefix in
NONE) program_prefix=my_default_ ;;
esac
should do the trick.
Put it somewhere between AC_IN
Thanks for your response, but it is not the kind of prefix I am looking
for. I am looking for the prefix prepended to the program name when
doing:
make install
For example, if my library has two programs, foo1 and foo2, and I do:
./configure --program-prefix=foopref_
when I do make install
JRBCAST wrote:
Hi all,
First of all, sorry if you have received this mail two times.
My question is: How can I set a default progra-prefix without the need
to explicitely pass it whith: ./configure --program-prefix ...
Look for AC_PREFIX_PROGRAM in the autoconf manual (4.12).
Another question
Hi all,
First of all, sorry if you have received this mail two times.
My question is: How can I set a default progra-prefix without the need
to explicitely pass it whith: ./configure --program-prefix ...
Another question is: Once the user sets it using ./configure --program-
prefix, which
Hi,
On Tue, Feb 08, 2005 at 12:44:46PM +0200, Philippe Trottier wrote:
> eval test -d `echo $libdir | sed 's,exec_prefix,prefix,'` &&
> eval LDFLAGS="-L`echo $libdir | sed 's,exec_prefix,prefix,'`
no big deal, what if I run
.
Stepan Kasal wrote:
Hi,
On Mon, Feb 07, 2005 at 03:40:02PM +0200, Philippe Trottier wrote:
here is something I have noticed, exec_prefix is set to NONE until the
end of the config script... now I am thinking to see if it is set at
NONE and if it is then set exec_prefix to ${prefix}, and put
Hi,
On Mon, Feb 07, 2005 at 03:40:02PM +0200, Philippe Trottier wrote:
> here is something I have noticed, exec_prefix is set to NONE until the
> end of the config script... now I am thinking to see if it is set at
> NONE and if it is then set exec_prefix to ${prefix}, and put i
Stepan Kasal wrote:
Hi,
On Fri, Feb 04, 2005 at 03:58:51PM +0200, Philippe Trottier wrote:
CPPFLAGS=-I${prefix}/include
LDFLAGS=-L${exec_prefix}/lib
Is there better way to expand ${prefix} other than using sed ?
here is something I have noticed, exec_prefix is set to NONE until the
end of
Hi,
On Fri, Feb 04, 2005 at 03:58:51PM +0200, Philippe Trottier wrote:
> CPPFLAGS=-I${prefix}/include
> LDFLAGS=-L${exec_prefix}/lib
>
> Is there better way to expand ${prefix} other than using sed ?
yes, use the shell builtin `eval'. The following macro can serve as
I have a little trouble here, I am trying to add the destination
directory "--prefix" to the library and header directorys to look in...
but since I am using ${libdir} and ${includedir} I get this
CPPFLAGS=-I${prefix}/include
LDFLAGS=-L${exec_prefix}/lib
and not /home/user/include
Hey I'm trying to get up to speed on the install variables that autoconf
uses. The doc that I have (for ver 2.59) says:
"...
Most of these variables have values that rely on |prefix| or
|exec_prefix|. It is deliberate that the directory output variables keep
them unexpanded:
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> On Tue, 21 Oct 2003, Bill Moseley wrote:
>> If I add a note to our README does is there any difference between:
>> LDFLAGS=-R/usr/local/lib
>> and
>> LD_RUN_PATH=/usr/local/lib
> You should provide the LDFLAGS option to configure. LD_RUN_PATH
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> When Sun introduced LD_LIBRARY_PATH in its operating systems (later
> adopted by Linux) it was described as a tool for use by developers
> rather than end-users. For Solaris, I prefer -R, but Linux and FreeBSD
> users will likely prefer to do without.
On Tue, 21 Oct 2003, Steven W. Orr wrote:
> =>A correct -R option needs to be specified, or set LD_LIBRARY_PATH
>
> May I suggest that you *not* use LD_LIBRARY_PATH? The real purpose of
> LD_LP is to allow a program to pick from multiple shared objects at
> loadtime. It's a bad thing to use this a
On Tuesday, Oct 21st 2003 at 14:29 -0500, quoth Bob Friesenhahn:
=>> What's happening is configure and make run fine, but ldd shows "not
=>> found" for libz's runtime linkage.
=>>
=>> I'm linking with zlib which is installed in /usr/local/lib, but it seems
=>> that on this machine (Solaris 2.6) th
On Tue, 21 Oct 2003, Bill Moseley wrote:
>
> If I add a note to our README does is there any difference between:
>
> LDFLAGS=-R/usr/local/lib
>
> and
>
> LD_RUN_PATH=/usr/local/lib
You should provide the LDFLAGS option to configure. LD_RUN_PATH is a
non-standard environment variable.
Bob
===
just make check.
If I add a note to our README does is there any difference between:
LDFLAGS=-R/usr/local/lib
and
LD_RUN_PATH=/usr/local/lib
> > Another thing that is confusing (and I'm not sure if it's related to why
> > configure is not failing the libz check) is t
nd I'm not sure if it's related to why
> configure is not failing the libz check) is that the problem only
> happens when using a --prefix setting.
>
> Without a --prefix the final link link has -R/usr/local/lib added.
> But if --prefix=/foo is used then that -R setting is *
gure is not failing the libz check) is that the problem only
> happens when using a --prefix setting.
That sounds pretty weird, but the problem would probably be with your
makefiles.
> It would be nice if configure would catch this. But I'm not sure if
> it's because configur
z is not found.
Another thing that is confusing (and I'm not sure if it's related to why
configure is not failing the libz check) is that the problem only
happens when using a --prefix setting.
Without a --prefix the final link link has -R/usr/local/lib added.
But if --prefix=/foo is us
On Fri, Jun 13, 2003 at 09:02:36AM -0400, Steve M. Robbins wrote:
> Autoconf and automake promote a standard for configuring, building,
actually it's autoconf (automake doesn't contribute).
> P.S. There may be valid reasons for changing the default prefix; I
> can think
s of
"edit defs.h; edit Makefile ..."
One of the standards promoted by autoconf is the notion of installing
into the hierarchy rooted at $prefix. There is a well-known method to
specify the prefix, and a well-known default if you don't. The
installation location ought to be a decis
On Thu, 12 Jun 2003, Steve M. Robbins wrote:
> However: if you plan to release the code for general consumption,
> think twice before using it. There are few things that irritate this
> software installer more than having "./configure; make install" put
> stuff somewhere OTHER than /usr/local.
a
On Wed, Jun 11, 2003 at 04:11:24PM -0500, Raja R Harinath wrote:
> Hi,
>
> <[EMAIL PROTECTED]> writes:
>
> > Is hacking definition of $(prefix) in Makefile.in the
> > best way to change default prefix from something other
> > than /usr/local???
> >
>
Hi,
<[EMAIL PROTECTED]> writes:
> Is hacking definition of $(prefix) in Makefile.in the
> best way to change default prefix from something other
> than /usr/local???
>
> Is there some macro to add to configure.in that would
> do the same? That seems like the ideal.
Tr
Is hacking definition of $(prefix) in Makefile.in the
best way to change default prefix from something other
than /usr/local???
Is there some macro to add to configure.in that would
do the same? That seems like the ideal.
Chris
So far all configure I have seen hard code /usr/local as base for
additional include/library path when doing checks (i.e.
-I/usr/local/include, -L/usr/local/lib, ...)
Is there any reason why autoconf does not automatically adds
$prefix/include, $prefix/lib etc (or more specific variants)? It is
IIRC, ``make install prefix=/tmp/foo'' is a GNU standard mandate where
prefix for the install does not modify the prefix for the build.
Earnie.
Harlan Stenn wrote:
Why don't you use DESTDIR instead?
IE:
> ./configure --prefix=/usr
> make
> make DESTDIR=/tmp insta
or DJGPP only use autoconf.
> IE:
>
> > ./configure --prefix=/usr
> > make
> > make DESTDIR=/tmp install
> > cd /tmp
> > tar cfz binary-tarball.tgz usr
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
> > Why don't you use DESTDIR instead?
>
> The install location is not always simply constructed by adding a set
> prefix to the run-time location.
The example I saw was just rolling a tarball for later installation.
> We have this discussion like clockwork about every
Harlan Stenn <[EMAIL PROTECTED]> writes:
> Why don't you use DESTDIR instead?
The install location is not always simply constructed by adding a set
prefix to the run-time location.
We have this discussion like clockwork about every three months.
--
Russ Allbery ([E
Why don't you use DESTDIR instead?
IE:
> ./configure --prefix=/usr
> make
> make DESTDIR=/tmp install
> cd /tmp
> tar cfz binary-tarball.tgz usr
H
Hello.
Philip Willoughby wrote:
[snip]
> Since the only reason I've been given to keep the variables unexpanded is
> so that you can do:
>
> ./configure --prefix=/usr
> make
> make prefix=/tmp/usr install
> cd /tmp
> tar cfz binary-tarball.tgz usr
>
> this see
Today, Dan Kegel wrote:
>Philip Willoughby wrote:
>> Since the only reason I've been given to keep the variables unexpanded is
>> so that you can do:
>>
>> ./configure --prefix=/usr
>> make
>> make prefix=/tmp/usr install
>> cd /tmp
>> tar c
Philip Willoughby wrote:
I've been thinking (shock!), and it seems to me that it wouldn't break
anything majorly if we did expand all the $prefix-dependant variables. The
reason being, practically everyone uses automake these days, and automake
defines all installation paths to be p
Am Mit, 2003-03-05 um 14.34 schrieb Philip Willoughby:
> I've been thinking (shock!), and it seems to me that it wouldn't break
> anything majorly if we did expand all the $prefix-dependant variables. The
> reason being, practically everyone uses automake these days, and aut
I've been thinking (shock!), and it seems to me that it wouldn't break
anything majorly if we did expand all the $prefix-dependant variables. The
reason being, practically everyone uses automake these days, and automake
defines all installation paths to be prefixed by $DESTDIR, which i
with the ongoing expansion of ac-archive, it started to problematic
to keep the macros sorted out. There has been a discussion a while
back whether it might make sense to reserve a macro-prefix for
those registered in the ac-archive - the usage of AX_ sounds best.
This AX_ prefix is now detected
John Poltorak wrote:
If I have prefix defined in config.site and use a diferent value on the
command line, which should take precedence?
I never use config.site, but I imagine the commandline should always
have the last word...
John Poltorak wrote:
If I have prefix defined in config.site and use a diferent value on the
command line, which should take precedence?
The command line.
Earnie.
If I have prefix defined in config.site and use a diferent value on the
command line, which should take precedence?
--
John
Apologies for not replying sooner: I've been away for a week.
Duncan Gibson asked:
DG> Is there any reason why the includedir related to a user-supplied
DG> --prefix (i.e. not /usr/local) isn't automatically added to the
DG> CPPFLAGS or internal search path when looking for
Duncan Gibson <[EMAIL PROTECTED]> [2002-10-17 11:57:21 +0200]:
> Is there any reason why the includedir related to a user-supplied --prefix
> (i.e. not /usr/local) isn't automatically added to the CPPFLAGS or internal
> search path when looking for header files?
Th
Is there any reason why the includedir related to a user-supplied --prefix
(i.e. not /usr/local) isn't automatically added to the CPPFLAGS or internal
search path when looking for header files?
I installed fltk-1.1.0 with --prefix=/scratch/duncan
I'm trying to create a configure.in
ement it.
the syntax model of automake isn't that well-suited to the problem,
since the input-file might something different, nor is the output
file always the same or the prefix that is to be used. Those are
the three optional arguments of the prefix-config macros. If you
have a prop
> Date: Mon, 18 Mar 2002 10:40:44 +0100
> From: Guido Draheim <[EMAIL PROTECTED]>
> If you have a proposal how to express that in automake-terms, don't
> hide it...
Sorry, I don't understand the overall problem well enough to draft a
solution. The only part of the problem that I understand has
Es schrieb Akim Demaille:
>
> > "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>
> Paul> Sorry, I don't understand the question. I went back and read
> Paul> the thread, and I still don't understand the question.
>
> Sorry for being confuse.
>
> Paul> I did understand Russ Allbery's po
>> $(output)
> echo "#endif /* PREFIX_CONFIG_H */" >> $(output)
>
> Pretty icky, but it does get the job done.
>
yes, that was my first shot too ;-) - it's seems to be the canonical
answer to the problem we have to handle and it seems to be a very
commo
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> Sorry, I don't understand the question. I went back and read
Paul> the thread, and I still don't understand the question.
Sorry for being confuse.
Paul> I did understand Russ Allbery's point. He wrote that if you
Paul> need a confi
> > my_config.h: config.h
> > sed 's/#define /#define MY_/; s/#undef /#undef MY_/' $@
It would appear I can air my dirty code :)
We define some of our own defines, that are already prefixed, so we
have to take care of the case of double prefixing. We also wrap the
header in an `#ifndef
> Date: Sun, 17 Mar 2002 13:48:30 +0100
> From: Guido Draheim <[EMAIL PROTECTED]>
> your point is quite fine - why not let the lines
> go into the makefile instead of config.status. I just wonder how to
> do this - if it would be possible then it would be fr better
> since `make` can take of
y_config.h: config.h
> sed 's/#define /#define MY_/; s/#undef /#undef MY_/' $@
>
> and once you do that, you don't nee Autoconf to generate my_config.h.
>
> Guido Draheim's rejoinder
> <http://mail.gnu.org/pipermail/autoconf/2002-February/012583.ht
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 13 Mar 2002 11:23:10 +0100
>
> My question is merely one of interface.
>
> Currently
>
> AC_INIT
> AC_CONFIG_HEADERS(config.h)
> AC_CONFIG_COMMANDS(config.h, [echo Hello, world])
> AC_OUTPUT
>
> is wrong (grr, it is not caught, I don't know why
> "Clinton" == Clinton Roy <[EMAIL PROTECTED]> writes:
Clinton> Guido Draheim <[EMAIL PROTECTED]> writes:
>> ... the other problem is that the prefixing is not done during
>> reconfig, and in fact, the items in my ac-macro should be appended
>> to the config.status file, which I didn't bother
ant depends on the generated header
> file, it will take care of making sure it's generated.
>
well, my ac-macro started out as some sed-lines in the makefile, but I
didn't wanted to copy it from project to project exchanging the prefix
which was always derived from the package name.
1 - 100 of 164 matches
Mail list logo
