Hi Bruno,
I like the idea of the patch, yet several people proposed patch along
this way, but I don't like the implementation. There's a lot of hair
which is due to the fact that you want to cache low level details,
such as what you computed. I think this is not right, you should
cache what you
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> Let's not add additional options to Autoconf that practically
Bob> no-one will use. In particular, a concise help output is most
Bob> helpful for newbies rather than experts who know what will work
Bob> in the first place.
Agreed.
UNAME_VERSION =
|
Regards,
Akim
Index: ChangeLog
===
RCS file: /cvs/config/ChangeLog,v
retrieving revision 1.25
diff -u -r1.25 ChangeLog
--- ChangeLog 2000/04/25 20:58:07 1.25
+++ ChangeLog 2000/05/02 10:36:53
@@ -1,3 +1,9 @@
+2000-05-02 Akim Demaille <[EMAIL PROT
> "Peter" == Peter Simons <[EMAIL PROTECTED]> writes:
Hi Peter!
Peter> So could someone please change the link on the web pages to
Peter> point to the new location? I'd appreciate that very much.
I will handle this. Thanks for the efforts you're putting in the
macro archive.
Akim
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Akim> Or else, it should be Automake who should communicate something
Akim> to Autoconf. That's a new situation. Maybe Automake could
Akim> create an m4 file with all the directories it needs. Kinda
Akim> bizarre, it never happened before.
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
F
Akim> IMHO the right patch is to teach `help2man' to `missing'.
Alexandre> Or adjust autoconf's Makefiles to proceed even if help2man
Alexandre> fails.
Hm, I don't understand: my understanding of `missing' is that you can
write
>>>>> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Quoth Akim Demaille: Does this seem feasible?
>> Very much.
>>
>> I share the opinion that too long a configure --help is painful,
>> nevertheless, on this prec
> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
Bruno> You should have seen the big patsubst while it was still in one
Bruno> big line :-)
:) :)
Just a note about changequote. Although you would certainly have
problems with the characters [ and ] themselves, there is really no
reason
> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
>> Just say no to
>>
>> changequote() patsubst($1, [^a-z]) changequote([, ])
>>
>> but welcome
>>
>> patsubst([$1], [[^a-z]])
Bruno> Ah! The outer [] are against m4, and the inner ones "[^a-z]"
Bruno> are the patsubst argument, right?
> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
>> Does [testing the signedness] make sense for other types than `char'?
Bruno> Yes. In particular size_t and wchar_t come to mind.
Wow, signed size_t :)
Where can we see that? What effect can it have so that you might need
to check fo
Hi!
Thanks for your contribution, but it is a bit too soon for such a
macro to integrate the core Autoconf. Rather, you should submit it to
| dnl @synopsis AC_caolan_FUNC_SNPRINTF
| dnl
| dnl Provides a test for a fully C9x complient snprintf
| dnl function.
| dnl
| dnl defines HAVE
Sorry, I forgot to past the url:
http://research.cys.de/autoconf-archive/
Akim
> "Jeffrey" == Jeffrey A Law <[EMAIL PROTECTED]> writes:
Jeffrey> You can't depend on ksh or sh5 being available on 4.3BSD
Jeffrey> boxes and the 4.3BSD shell certainly does not support shell
Jeffrey> functions.
Hi Jeff,
Thanks for the feedback. But I am still suspicious. There are way
to
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> Hi!
dv> While writing a macro to be aclocal'ed, I discovered that
dv> the m4 macro `eval' is not expanded by autoconf. I guess that's a
dv> `feature', since snarfing in the code gave me the feeling that I'm
dv> su
Well, we already have AC_PACKAGE, AC_COPYRIGHT (shouldn't it be
AC_LICENSE btw?), and now AC_COMMENT.
I don't feel good to see those names being used. Maybe we should use
a sub name space? Either a new one, or CONFIG: AC_CONFIG_PACKAGE,
AC_CONFIG_COMMENT?
Grmph. Maybe not.
> "Michael" == Michael Bletzinger <[EMAIL PROTECTED]> writes:
Michael> When running a configure.in script that has no AC_DEFINE
Michael> calls the config.status script that is generated contains any
Michael> empty if/then/fi structure which bash croaks on. This patch
Michael> fixes the behav
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:
Lars> There is no bug in autoheader.
Lars> autoheader itself is a bloody bug,
Wow :) What is it that is so wrong with autoheader? How can you
imagine leaving with it? I certainly don't want to write my
config.h.in by hand, and I do w
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> I worked around this issue by always using 3 arguments to
Mo> AC_DEFINE.
Nope, you just did the right thing :)
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Hmm. I'm pretty sure autoconf 2.13 set target to "NONE".
Yes, it did, definitely. But it makes the code much simpler not to
give a default value. Now, if you think this is the beginning of
troubles, we might change it back :(
Your point is very valid. Could you come up with a specification of
what you think should be the right behavior? autoheader could check
that the set of the AC_CONFIG_HEADERS properly templates all the
symbols which are used.
Or a missing template could be a warning instead of an error. I don'
> "Keith" == Keith Thompson <[EMAIL PROTECTED]> writes:
Keith> I recently discovered that the generated configure scripts have
Keith> problems when the software is installed in a directory whose
Keith> name contains ':' characters. (I was using a timestamp as part
Keith> of the directory nam
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> How can you imagine leaving with it?
Gromph, sorrys/it/heat/ :)
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Greg> One of the things that I find frustrating in 'autoconf' is that
Greg> dependencies between configuration tests are not explicit.
Tom> FWIW: this is one of the things that Metaconf (the package used
Tom> to build Perl-style Co
Are you sure your patch changes something? I mean, the problem is
probably with the confdefs.undef file, not confdefs.defines:
confdefs.defines part:
| # Break up conftest.defines because some shells have a limit on the size
| # of here documents, and old seds have small limits too (100 cmds).
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> IMHO, AC_REQUIRE and AC_BEFORE are broken by design.
Sorry, but I find your judgment a bit severe.
dv> Or at least, their behavior is far too basic (notably the calling
dv> of the required macro without any argument)to be satisfactory
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
Akim> Why can't we expect sh5 being available?
Ian> Because sh5, as indicated by its name, is the System V shell. It
Ian> will not be found on a pure BSD system. Similarly, ksh, the Korn
Ian> shell, is a Bell Labs invention made well
,
| AC_PREREQ(2.14a)
| AC_INIT(configure.in)
| AC_CONFIG_SUBDIRS(sub) dnl calls AC_CONFIG_AUX_DIR_DEFAULT
| AM_INIT_AUTOMAKE(test, 1)
| AC_CONFIG_AUX_DIR(aux) dnl Wrong: second call to AC_CONFIG_AUX_DIRS
| AC_OUTPUT(Makefile)
`-
Your point is valid, but I think you just reveal
>>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Well, you are right, it is new that they are being renamed,
Akim> before they were just removed :)
Tom>
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> You're right. Actually, I just discovered that autoconf
dv> doesn't print warnings anymore by default, which partly explains
dv> the surprises I recently got with some macros ordering problems.
I can reenable the `syntax' categor
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> This might be a stupid (because blind) question, but instead of
dv> renaming m4 macros as m4_*, wouldn't it be better to let m4 alone,
dv> and use a prefix for autoconf itself, like au_* ?
Nope, because it belongs to a sub part named `li
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> Well, that's good news. Given your point of view on
dv> AC_REQUIRE [1], and the fact that the doc says "_suggested_
dv> ordering" about AC_BEFORE,
The doc is accurate until we fix this.
dv> [1] as expressed earlier in this threa
Hi,
I will shortly commit a patch which changes the signature of the three
macros above (they are new and were never released).
We no longer rely on parens for the m4 list, rather we rely on the
quotation:
For instance:
-AC_CHECK_DECLS((strlen))
-AC_CHECK_DECLS((malloc, realloc, calloc, free)
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> Tom Tromey wrote:
>> Is an AC_BEFORE violation really just a warning?
dv> yes.
>> I think it is an error.
dv> That's what Akim and I fight about all day long. Akim sees
dv> it as a `convenience' and doesn't think someth
> "R" == R Leigh <[EMAIL PROTECTED]> writes:
>> It seems to me that you don't know yet the changes undergone in CVS
>> Autoconf :(
R> Yes, sorry about that. The Solaris system that gives me internet
R> access does not have pserver available.
If you're extremely patient, you might want to tr
> "R" == R Leigh <[EMAIL PROTECTED]> writes:
Hi!
It seems to me that you don't know yet the changes undergone in CVS
Autoconf :(
R> 1. To scan configure.in intelligently for all definitions.
This is what autoheader does.
R> 2. To create config.h.in (by default) with the definitions.
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> The next interesting question would be if ksh alters its
Russ> behavior if invoked as sh instead of as ksh. Hm. (Thanks for
Russ> the note; I was vaguely aware of that but had forgotten it when
Russ> I was writing the last message.)
> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes:
Paul> I'm a little concerned that the & token isn't supported by all
Paul> versions of sed, either, but I couldn't find any
Paul> examples... anyone have thoughts on the portability of that?
Hm, I never heard of portability issues on that
| Hi There,
Hi!
| autoconf picks "gcc" as the compiler and "cc -E" as the preprocessor
| when I do not specify CC or CPP.
Could you try to track down the problem, I cannot reproduce it:
/tmp % cat configure.in nostromo 14:06
AC_INIT
AC_PROG_CC
AC_PROG_
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Gary> Hmm. I'm pretty sure autoconf 2.13 set target to "NONE".
Akim> Yes, it did, definitely.
Gary> Nup. No problem with the change here.
Alexandre> I think I've alread
| The current binutils code uses sinclude. There is one copy of
| acinclude.m4 which is used by several configure.in files. The
| acinclude.m4 files in the other directories just say
| sinclude(../bfd/acinclude.m4)
|
| This could be handled via some sort of option to aclocal to tell it
| w
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> 1/ It is not documented. Is it intentional or just an ommision ?
A bit of both. If you think this is the right signature, please
proceed a submit an update of the documentation.
dv> 2/ AC_PACKAGE_BUGREPORT is not used anywhere. Same qu
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> Hi!
dv> Would it be possible for autoconf to load the site and
dv> local macro files (like aclocal.m4) *before* the call to AC_INIT ?
dv> There are times when you want to call your own macros before
dv> AC_INIT (I
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello! How about removing the old testsuite? It is not used
Pavel> anywhere. "make dist" will not include it into the
Pavel> distribution.
Err, it has been `cvs remove'd though. I think I did right: I know
longer have testsuite/
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On May 12, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>>>>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
>> Err, it h
Thanks, done :)
Hi!
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> The cleanest way to do this is to have a ~/.cvsrc containing:
Alex> update -P -d checkout -P
Alex> The -P options prune empty directories and the -d option gets
Alex> new directories (update ignores them by default).
Ok, I've d
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> Hi!
Salut !
dv> Here's an attempt to implement warning disabling by passing a
dv> `no' argument to -W (or in the WARNINGS env var. The
dv> `syntax' category is also turned back on by default.
This is not enough: -Wall,nosyntax will
[Moved to [EMAIL PROTECTED]]
> "Pierre-Julien" == Pierre-Julien Grizel <[EMAIL PROTECTED]> writes:
Pierre-Julien> How can I extend the current
Pierre-Julien> (/usr/share/autoconf)/acconfig.h to allow my library
Pierre-Julien> package to define the HAVE_LIB_OFMYOWN macro without
Pierre-Julie
Well, Didier and I talked about this issue, and, correct me if I
misunderstood, it seems that the primary issue is the fact that some
macros need to be before AC_INIT, while most others should not.
I've been bugged by this too, and, hit me if I'm wrong, all (y)our
troubles will vanish if *any* m
I should warn you that there is a known bug in the current CVS
Autoconf: if `./configure' receives two or more arguments, they are
improperly given to `./config.status', hence `./config.status
--recheck' will not perform its tasks correctly. AC_CONFIG_SUBDIRS is
probably affected too.
I'm worki
Hi Bruno,
Here is my interpretation of your work. Alexandre, what do you think
about it?
This implementation requires CVS Autoconf. Install it as
`configure.in' and CVS autoconf it to give it a try.
# aclang.m4
# AC_LANG_BOOLEAN(PROLOGUE, EXPRESSI
Index: 0.300/ChangeLog
--- 0.300/ChangeLog Sun, 14 May 2000 07:36:36 +0200 akim (ace/34_ChangeLog 1.272 664)
+++ 0.300(w)/ChangeLog Sun, 14 May 2000 08:38:23 +0200 akim (ace/34_ChangeLog 1.272
+664)
@@ -1,5 +1,21 @@
2000-05-14 Akim Demaille <[EMAIL PROTECTED]>
+ Either we cross-compil
> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
Bruno> Hi Akim, Your implementation indeed has the aesthetics you were
Bruno> asking for; congratulations.
Thanks :)
>> `conftestdate'.
Bruno> That should be `conftestval', not `conftestdate'.
Gromph, thanks!
Akim
> "ois" == ois Pinard writes:
> So, if `missing' ever replaces `install-sh' and `mkinstalldirs',
> this should be seen as a good thing, absolutely in the spirit of the
> design of `missing'.
I share your opinion.
And to answer to the fact that missing is currently part of the
Automake ki
> "Ossama" == Ossama Othman <[EMAIL PROTECTED]> writes:
Ossama> I'm really looking forward to the latest Autoconf!
So do I, so do I :)
Paul said:
| This is what I would consider the best solution:
|
| a) By default, all instances where a simple program can't be run after
| linking successfully are treated as immediate, fatal errors, and a
| message indicating "your compiler is broken" is printed.
Agreed.
| b) There
> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes:
Paul> First, IMO warnings aren't good enough.
I agree with you, sincerely I do. Nevertheless Autoconf cannot be
changed like this, we need a general agreement first. Maybe I should
have presented my proposal the other way round: have it
> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes:
Paul> Yes, but it prevents them in a way that makes it _MORE_ likely
Paul> that you will get the wrong behavior, instead of _LESS_ likely
Paul> (IIUC).
I understand your grief: the fact that in case of conflict, the
cross-compiling assumpt
> "Ossama" == Ossama Othman <[EMAIL PROTECTED]> writes:
Ossama> Again, I admit that I can't think of any reason why anyone
Ossama> would want such a configuration, but IMHO autoconf should not
Ossama> be so restrictive.
I think it should. It should propose the Right Way To Do It to the
peop
Hi!
Your problem is probably that Autoconf did not pick the right m4, and
probably tried the Solaris' version instead of your GNU m4.
To help it, try
M4=/path/to/gnu/m4 ./configure
or be sure to have your PATH which first visits the directory where
GNU m4 is.
Akim
> "Ossama" == Ossama Othman <[EMAIL PROTECTED]> writes:
Ossama> Paul, I think that for the most part I agree with your
Ossama> suggestions. Now on to Akim. :-)
Waiting for you :)
> "Ossama" == Ossama Othman <[EMAIL PROTECTED]> writes:
Ossama> BTW, my comments below are more design philosophy related in
Ossama> nature than actual proposals for a change.
Nah, you don't need any excuse for expressing yourself :)
>> I'm not sure to understand what you are referring to
| On May 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| > + Either we cross-compile the whole package, or we don't.
| > + Using --host explicitly enables cross-compilation.
|
| Ok
|
| > +AC_MSG_WARN([the C compiler is not a cross compiler as was expected]);;
> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes:
ad> Well, gentlemen, I think a major step forward has just been made.
ad> Paul must be very happy, it's been years that he militated for
ad> this :)
Paul> I'm breakin' out the champagne and virtually toasting you! :)
Hips! Thanks! :)
Pa
>>>>> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Akim Demaille writes:
>> Here is my interpretation of your work.
Peter> That looks very nice, but there is one problem I see: When
Peter> cross-compiling, AC_CHECK_SIZEOF with a n
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Akim> I understand the need, I don't understand `sinclude'. It seems
Akim> to me you want `include', not `sinclude'.
Ian> Ignorance, I think. I think I just copied sinclude from some
Ian> other m4 script.
Tom> ISTR that autoconf disabled "
> "Nicolas" == Nicolas Joly <[EMAIL PROTECTED]> writes:
Nicolas> Hi,
Nicolas> I just updated and tested latest CVS autoconf under Digital
Nicolas> Unix v5.0. I noticed a problem in _AC_INIT_PARSE_ARGS
Nicolas> (acgeneral.m4).
Nicolas> Many shells, such Digital Unix v5.0 /bin/sh , do not al
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I should warn you that there is a known bug in the current CVS
Akim> Autoconf: if `./configure' receives two or more arguments, they
Akim> are improperly given to `./config.status'
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On May 21, 2000, DEMAILLE Akim <[EMAIL PROTECTED]> wrote:
>> This point is that if the user did not --build, then
>> $build_alias='' likewise for the two others. Before, $build_alias
>> would have been the same as as $bu
| > bug in `configure.in'. Must we be bugward compatible?
| bugward :)
|
| I think so, cf. below.
I think below you do demonstrate that a buggy configure.in will see
the bug revealed by this patch. I agree on this. My question is
more:
Is being bugward compatible more important tha
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On May 22, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> To me that's a bug which would be revealed by this patch, but it's
>> a bug in `configure.in&#
| Akim Demaille wrote:
| >
| > | > bug in `configure.in'. Must we be bugward compatible?
| > | bugward :)
| > |
| > | I think so, cf. below.
| >
|
| > | > If so, we can
| > | > set host to host_alias at the end of the handling of the options,
| >
This was fixed yesterday.
> "Ossama" == Ossama Othman <[EMAIL PROTECTED]> writes:
>> Assigning values to CFLAGS is _MUCH_ simpler, more straightforward,
>> and flexible, IMO.
Ossama> I think you're right Paul. I just needed to discuss this
Ossama> stuff so that I could better understand why things are the way
Ossama
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On May 21, 2000, DEMAILLE Akim <[EMAIL PROTECTED]> wrote:
>> This point is that if the user did not --build, then
>> $build_alias='' likewise for the two others. Before, $build_alias
>> would have been the same as as $bu
>>>>> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> On 23 May 2000, Akim Demaille wrote:
>> So, do you people think the patch should be applied as is? Anyway,
>> if there are real problems, we will quickly know during the beta
>
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> I believe negated character ranges were added to /bin/sh around
Paul> the same time as shell functions. They are definitely absent
Paul> from the Unix Version 7 sh documentation (I just checked).
Is the doc you are referring to the
On 23 May 2000, Akim Demaille wrote:
> How would you write this:
>
> case $ac_package in
> [*[^-a-zA-Z0-9_]*]) AC_MSG_ERROR([invalid package: $ac_package]);;
> esac
| Your example could be rewritten to use a dummy case which is the
| complement, and changing
| all your script is saying is that if it finds a package with
| non-alphanumeric (or _) characters, to print an error. If you
| make it something like this (an if-statement this time ;-):
|
| changequote(,)
| if test -n "`echo .$ac_package |sed -e 's/[a-zA-Z0-9_]//g'`"
| changequote([,
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> So, how about setting both of host and host_alias from the
Alexandre> command-line arguments, just for the sake of backward
Alexandre> compatibility? We should still recommend the use of
Alexandre> *_alias before AC_CANO
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Akim>expr has a bad reputation
Paul> Its syntax is awkward -- was that what you were thinking about?
Nope, I was referring to the portability. And precisely about the
syntax, is `match string expr' portable?
Paul> expr is already men
Currently to find out if we are under one of these environments
configure runs a compilation, typically to see if __CYGWIN__ is
defined etc.
Can't we do this kind of checks *without* compiling? IIUC correctly,
for Autoconf to be really DJGPP aware, we'd need to change things
which do not depend
Updated. AC_CHECK_SIZEOF has never been released with support of
shell variables, not my stepping back is backward compatible, and
there is no real loss.
/tmp % ./configure nostromo 12:08
checking for gcc... gcc
checking whether the C compiler works
| Giving a shell variable to AC_CONFIG_LINKS like this doesn't work in
| recent CVS versions of Autoconf:
|
| foo="link:file"
| AC_CONFIG_LINKS($foo)
|
| I assume it's because `config_links' is set in config.status by
| configure doing
|
| cat >$CONFIG_STATUS <<\EOF
|
|On May 25, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
|> # AC_LANG_BOLL_COMPILE_TRY(PROLOGUE, EXPRESSION)
| s/BOLL/BOOL/
Lps, thanks!
Is this a LK?
jk: dju Y dfgg qwer tyu]
Akim> jk: dju Y dfgg qwer tyu]
Llps, slrry, I meant
Nl, but I wioo send lne!
@@
+2000-05-26 Akim Demaille <[EMAIL PROTECTED]>
+
+ Find a means to extract integers from the compiler.
+ Use this technology to compute `sizeof' even when cross-compiling.
+ Ideas and initial suggestion by Kaveh Ghazi.
+ Binary search by Bruno Haible.
+
+
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Really cute :-) Congrats,
Thanks :) I still wonder about the name (_AC_COMPUTE etc.). I don't
know too well.
Alexandre> sizeof(char) == 1 always holds, but it doesn't have to be a
Alexandre> byte.
Aha! indeed. Than
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> I agree we could have a hard error in case the user doesn't
Alexandre> specify --host but an executable produced by the compiler
Alexandre> won't run.
Well, gentlemen, I think a major step forward has just been made.
Pau
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> How much interest would there be in adding Java to the > autoconf
Mo> supported languages?
Alexandre> I'd certainly welcome this effort, but I don't think this
Alexandre> is something for autoconf 2.50.
Mo> I am not really interested in do
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> But we have to be careful, since there are two (three?)
Alexandre> kinds of Java compilers: those that translate Java source
Alexandre> to bytecode, and those (that?) that translate(s?) Java
Alexandre> source (or bytecod
> "Paul" == Paul Berrevoets <[EMAIL PROTECTED]> writes:
>> If you want to get folks using and improving Java macros, you need
>> to make them part of the "standard" install.
Paul> I concur that Java is ubiquitous enough to warrant "standard"
Paul> support.
The long range goal is to have Aut
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> mo(~/project/SDL)% grep AC_CHECK_TOOL_PREFIX *
Mo> acinclude.m4:[AC_REQUIRE([AC_CHECK_TOOL_PREFIX])dnl
Mo> This acinclude.m4 file seems to have been generated by libtool.
:( OK, thanks, will add a stub for it.
| Seeing as how Akim wants DJGPP to pass the testsuite, I figure it would be a
| good idea report my initial results using DJGPP and Autoconf from CVS.
Thanks a lot!
| After setting some environment variables (CC, etc.) and correcting a DJGPP
| specific bug in Bash 2.04, the test went well wi
> "Steven" == Steven G Johnson <[EMAIL PROTECTED]> writes:
Steven> My inclination is to think that the list of things "required"
Steven> for 2.15 is a little overly ambitious. If some minor issue is
Steven> unchanged from 2.13, e.g. not enough environment variables
Steven> being documented,
| > Could you give more details on these steps? What can be done to have
| > it right without tuning by hand?
|
| What I set is:
| PATH_SEPARATOR=:
| TEST_FINDS_EXE=Y
Wow, are you telling us we no longer need to dive into `test $ac_x'
and things like this?
| CC=gcc
That's a known problem of
There are several macros in Autoconf that are checking whether a
function exists and works and set HAVE_FUN accordingly. This is the
strategy I adopted when I stole AC_FUNC_GETGROUPS from Jim, although
his original macro was defining HAVE_WORKING_GETGROUPS.
I think Autoconf should advocate a si
| Hi,
|
| In a package I'm integrating autoconf into, I need to be able to
| support cross-compiling. Specifically, the libraries in the package
| will be cross-compiled. However, the package contains a compiler
| binary that must be run on the build platform, not the host platform.
| This mea
Maybe you fell on the AC_REQUIRE problem which was once pointed out by
Axel Thimm. I'll try to adapt his patch to CVS Autoconf. But maybe
it is unrelated, and is caused by the fact that Libtool has to do a
lot of things which are very intimate with Autoconf. But Autoconf is
responsible for thi
301 - 400 of 1987 matches
Mail list logo
