> "Bernard" == Bernard Dautrevaux <[EMAIL PROTECTED]> writes:
>> The reason why you can't depend upon this is that somewhere, IMHO,
>> it is just wrong to expect make prefix=/foo to work properly.
>> Specifying prefix etc. is a job for configure, not make.
Bernard> You should be more precise
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
>> I didn't know stow would rely on this. But still, it seems
>> dangerous to me: why don't you ./configure
>> --prefix=/usr/stow/mypackage.mj.mn.p in order to be sure that the
>> hard coded paths are right?
>>
Earnie> No. The hard cod
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> DESTDIR is completely unusable for this situation because
Russ> DESTDIR requires a complete replication of your final file
Russ> system structure under the DESTDIR root, which isn't how this
Russ> normally works. DESTDIR is more inte
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> Yes, but what I am asking for is to actually set the prefix and
Mo> exec_prefix variables after reading the command line options in
Mo> ./configure, and then pass them correctly to ./config.status.
I answered to this elsewhere: there are so
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jul 19, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>> Has anyone come up a reason why setting the ${prefix} and
>> ${exec_prefix} variables at the top of ./configure would be bad?
Alexandre> I think the point is to be
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> (BTW, on this general subject, I'll take this opportunity to
Russ> publically complain about the internationalization message
Russ> catalogs in nearly every GNU package that I've run across, which
Russ> rather than obeying the setting
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Maybe AC_CANONICAL_BUILD should do nothing in case it is
Alexandre> invoked multiple times? This would be a nice plus for
Alexandre> backward compatibility.
It does nothing (i.e., it is expanded once). The three of the
On Jul 20, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Maybe AC_CANONICAL_BUILD should do nothing in case it is
Alexandre> invoked multiple times? This would be a nice plus for
Alexandre> backward compatibility.
> I
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jul 20, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]>
>>> writes:
Alexandre> Maybe AC_CANONICAL_BUILD should do nothing in case it is
Alexandre> invoked m
> Thomas E Dickey writes:
> how are you going to enforce it?
> (is there a tool...)
Right now I will just enforce it manually. My converter doesn't parse
the macro contents at the moment and I don't really want to start
adding that feature as I am sure it will not work in 100% of all cases
> "Peter" == Peter Simons <[EMAIL PROTECTED]> writes:
> Thomas E Dickey writes:
>> how are you going to enforce it? (is there a tool...)
Peter> Right now I will just enforce it manually. My converter doesn't
Peter> parse the macro contents at the moment and I don't really want
Peter> to
On 20 Jul 2000, Akim Demaille wrote:
> > "Peter" == Peter Simons <[EMAIL PROTECTED]> writes:
>
> > Thomas E Dickey writes:
> >> how are you going to enforce it? (is there a tool...)
>
> Peter> Right now I will just enforce it manually. My converter doesn't
> Peter> parse the macro cont
--- Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> Earnie> I understand your point but you must be flexable on this. I
> Earnie> do expect that the prefix is changeable at the time of make.
> Earnie> My guess is that others do also.
>
> Yep, but really if you want to understand what I meant, you
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> His example quoted both the macro names (simple) and their
Thomas> content (harder). I was asking about the latter.
I see.
Parsing m4 is definitely a hard task. Either use m4 to do that, or
just use a simple heuristics. In
On 20 Jul 2000, Akim Demaille wrote:
> > "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
>
> Thomas> His example quoted both the macro names (simple) and their
> Thomas> content (harder). I was asking about the latter.
>
> I see.
>
> Parsing m4 is definitely a hard task. Either u
I'm reposting my original message because I never heard from anyone on
this. Does anyone have any idea on this. I looked through autoconf's m4
macros and couldn't figure out how to make this happen. Thanks.
---Original
I'm curious if there is a way to make autoconf expand variables
completely. Ta
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> On 20 Jul 2000, Akim Demaille wrote:
>> > "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
>>
Thomas> His example quoted both the macro names (simple) and their
Thomas> content (harder). I was asking about the latt
Karl Fogel <[EMAIL PROTECTED]> writes:
> Autoconf 2.13 can't distinguish between --version and --verbose options.
This has been fixed in the -current autoconf where there's both a
--version and a --verbose option.
/assar
Akim Demaille writes:
> I don't recall well why we recently chose .cc for C++. ISTR it was
> because before we used `.C' which is not a good choice in case
> insensitive environments. Ossama had suggested `.cpp', but I chose
> `.cc' because `locate(1)' on my system found more `.cc' and no `.cpp
>From what you gave ...
configure.in:
AC_INIT(test.in)
PACKAGE=test
CP_PREFIX=/usr/local
CP_LIBDIR=$CP_PREFIX/lib
CP_PKGLIBDIR=$CP_LIBDIR/$PACKAGE
AC_SUBST(CP_PREFIX)
AC_SUBST(CP_LIBDIR)
AC_SUBST(CP_PKGLIBDIR)
AC_OUTPUT(test)
test.in:
@CP_PREFIX@
@CP_LIBDIR@
@CP_PKGLIBDIR@
$ ./configure
creatin
That's what I want but that's not what I get. When configure does it's
substitutions it doesn't seem to expand variables that are used to
define other variables. If that worked for you I guess I need to figure
out what's different. Thanks!
Paul Berrevoets wrote:
>
> From what you gave ...
>
> c
Ti Leggett wrote:
> That's what I want but that's not what I get. When configure does it's
> substitutions it doesn't seem to expand variables that are used to
> define other variables. If that worked for you I guess I need to figure
> out what's different. Thanks!
This will happen if you use
Ahhh I didn't even see those (and haven't had a chance to do much
testing). Thanks! Now if I only could figure out how to use $prefix,
$libdir, $sysconfdir, etc. in configure.in. Also, is there a way to have
@libdir@ expanded out instead of to the default ${prefix}/lib that it
goes to? Thanks!
23 matches
Mail list logo
