I want to verify that a program is in the path, and error if it isn't. If
it is, I'd like the value of the MKAFSVOL variable to make it into
the config.h file that gets written for other stuff. How do I properly
put that value into the file?
This is how I'm currently checking for the program in
> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes:
Patrick> I'm happy to try suggestions.
Hi!
Thanks for the report. The problem is most probably that your sed is
not GNU sed. For the time being I don't know too well what to do: get
rid of this limitation (but then I know that anyw
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jul 3, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>> I think it might be a good idea to add the -pipe option to the
>> default CFLAGS if gcc is detected and the -pipe option is
>> supported. What do you think?
Alexand
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jul 4, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>> If it makes the build go faster for 99% of the folks out there, we
>> should use it.
Alexandre> Does it? I really don't know.
I don't know either for sure, but I'
| I want to make sure that two functions are available, and die if they're
| not.
|
|
| AC_CHECK_FUNC(seteuid, AC_DEFINE(HAVE_SETEUID, 1), AC_MSG_ERROR([This
| program re
| quires that seteuid be available]))
|
| AC_CHECK_FUNC(getpwent, AC_DEFINE(HAVE_GETPWENT, 1), AC_MSG_ERROR([This
| program
Akim Demaille writes:
> > "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
[...]
> Alexandre> I think this should not be done by default. -pipe is more
> Alexandre> CPU-intensive than regular builds, so it should be up to
> Alexandre> the builder to decide whether to use it or not.
I took a pass at the most recent --build --host stuff in
the CVS version and it looks like it is *almost* ready.
The first thing we to do was change the warning message.
It is confusing and does not really tell me that things
could still change based on what is detected at runtime.
Here is the ch
On 4 Jul 2000, Akim Demaille wrote:
> > "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes:
>
> Patrick> I'm happy to try suggestions.
>
> Hi!
>
> Thanks for the report. The problem is most probably that your sed is
> not GNU sed. For the time being I don't know too well what to do:
On Jul 4, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> configure: WARNING: For backwards compatibility, --build will be set to --host
> if a cross compiler can not be found
This is not true. Akim committed the patch without updating the
documentation. Now, --build is guessed unless explic
On 4 Jul 2000, Alexandre Oliva wrote:
> On Jul 4, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > configure: WARNING: For backwards compatibility, --build will be set to --host
> > if a cross compiler can not be found
>
> This is not true. Akim committed the patch without updating the
>
On Jul 4, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> On 4 Jul 2000, Alexandre Oliva wrote:
>> On Jul 4, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>>
>> > configure: WARNING: For backwards compatibility, --build will be set to --host
>> > if a cross compiler can not be found
>>
>> This
On 4 Jul 2000, Alexandre Oliva wrote:
> Can you point to any configure.in code for which this makes any
> difference? Remember, we're just not setting build_alias=$host_alias
> any more. We won't be assuming cross-compilation just because they
> happen to be different, in this case.
There is n
Ok, here is a patch like the last one except that it does
not change anything related to --build and --host. It does
improve the warning that gets printed (IMHO) and it fixes
a couple of bugs in AC_CHECK_TOOLS and AC_LANG_COMPILER_WORKS.
I don't think we want to actually encourage the use of
--bui
Hi,
I have attempted a rewrite of the above two macros, after several
people asserted that there was a (although harmless) logical glitch.
The macro now distinguishes 3 independent types of behaviour:
- case mangling
- underscore appending (normal)
- additional underscore for symbols alre
Date: Mon, 3 Jul 2000 04:34:50 -0700 (PDT)
From: Mo DeJong <[EMAIL PROTECTED]>
I have noticed that there are a number of packages that
include extra code to test for and enable the -pipe
option to gcc. I think it might be a good idea to add
the -pipe option to the default CFLAGS
>I have noticed that there are a number of packages that
>include extra code to test for and enable the -pipe
>option to gcc. I think it might be a good idea to add
>the -pipe option to the default CFLAGS if gcc is detected and
>the -pipe option is supported. What do you think
Stay away from -pipe.
Older gcc's had the behavior of if you did:
gcc -pipe -save-temps
the -pipe would override -save-temps
(this changed I believe in newer versions).
This seems to be developer/installation specific, rather than
an autoconf issue...
Marty
Is the present state of the CVS version of autoconf "stable enough" for
production use?
It looks like a couple of folks are getting ready to start cross-compile
efforts for new releases of NTP, and I need to decide if I should upgrade or
hold still...
H
On Tue, 4 Jul 2000, Harlan Stenn wrote:
> Is the present state of the CVS version of autoconf "stable enough" for
> production use?
>
> It looks like a couple of folks are getting ready to start cross-compile
> efforts for new releases of NTP, and I need to decide if I should upgrade or
> hold s
I just noticed that the more I run ./config.status --recheck the
more CFLAGS arguments show up in ./configure line that gets
rerun. (This is after two re-configures)
% make
/bin/sh ./config.status --recheck
running /bin/sh /home/mo/project/tkgs/configure CFLAGS=-g -O2 CFLAGS=-g
-O2 --host=i386-
20 matches
Mail list logo
