Re: Forcing an AC_CHECK to fail

[Ralf Wildenhues]

Hello Michael,

* Michael B Allen wrote on Sun, Oct 21, 2007 at 02:44:26AM CEST:
> On 10/20/07, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> > "Michael B Allen" <[EMAIL PROTECTED]> writes:
> >
> > > So how to do I preset a cache variable before running configure?
> >
> > You can put it in the environment, or use config.site.  See
> > (autoconf)Site Defaults.

> Ok. I see the docs you're talking about. Still not crystal clear what
> exactly I would put in the site config (AC_CACHE_VALUE I suppose).

To find out the cache value name, either look at the generated configure
code, or do a `./configure -C' and look for the corresponding variable
in the generated config.cache file.  Variables are named according to a
scheme:


Cheers,
Ralf

Re: Infinite recursion with `check_SCRIPTS = check'

[Ralf Wildenhues]

Hello Benoit,

* Benoit SIGOURE wrote on Sat, Oct 20, 2007 at 01:58:23PM CEST:
> Hello list,
> Due to a sudden lack of imagination, I wrote a testsuite named `check' and 
> used it as a `check_SCRIPTS' which led to an infinite recursion of make 
> (because the .PHONY check depends on check-am which does a `$(MAKE) 
> $(AM_MAKEFLAGS) $(check_SCRIPTS)' so the make has no chance of catching the 
> dependency cycle).
>
> Maybe automake should warn (or bail out) in such a case.  I can write a 
> patch for that, if you think that could be something relevant.

Well, the user should be able to override the `check' target if he so
wants.  If it's possible to reliably warn without giving false failures
without a lot of work, then it would help.  But often such checks turn
out to be rather expensive in both developer time and automake run time.

> Maybe something along these lines would be better:
> diff --git a/automake.in b/automake.in
> index 3c47cc1..263674c 100755
> --- a/automake.in
> +++ b/automake.in
> @@ -6826,8 +6826,10 @@ sub am_primary_prefixes ($$@)
>  # Handle `where_HOW' variable magic.  Does all lookups, generates
>  # install code, and possibly generates code to define the primary
> -# variable.  The first argument is the name of the .am file to munge,
> -# the second argument is the primary variable (e.g. HEADERS), and all
> +# variable.  The first argument can be one of: '-noextra', '-candist',
> +# or '-defaultdist'.  FIXME: Document these options.
> +# The following argument is the name of the .am file to munge,
> +# the following argument is the primary variable (e.g. HEADERS), and all
>  # subsequent arguments are possible installation locations.

Sorry, but I don't understand at all what you're trying to say here.

> If I have some time next week, I'll try to port the parallel testsuite 
> thing that Akim wrote

That would be great!

Cheers,
Ralf

Re: Makefile.am assistance

[Ralf Wildenhues]

* NightStrike wrote on Fri, Oct 19, 2007 at 09:25:08PM CEST:
> 
> crt_SCRIPTS = libcrtdll.a libmsvcrt.a libmsvcr80.a
> libcrtdll.a libmsvcrt.a libmsvcr80.a:
> base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
> $(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
> $(top_srcdir)/$${base}.def
> 
> To generate those three libraries, I do nothing other than run
> dlltool, passing in the appropriate .def file.

Let's deal with one library only.  For the moment, leave Automake out of
the picture, this is a mere issue of how to write 'make' rules.

Am I right in that the input files to dlltool in this case are
foo.dll and foo.def, and the output is the import library libfoo.a?

Then write
  libfoo.a: foo.dll foo.def
rule...

for each library.  If you can require GNU make (which I guess you can),
then you can write one pattern rule
  lib%.a: %.dll %.def
rule...

> Do you know how to achieve the above effect with using the _LIBRARIES
> primary instead of overriding the use of _SCRIPTS?

Well, I could tell you that Libtool can create DLLs plus import
libraries (it names them libfoo.dll.a), but I don't think you want
to hear that at this point.  ;-)

Cheers,
Ralf

Re: Infinite recursion with `check_SCRIPTS = check'

[Benoit SIGOURE]

On Oct 21, 2007, at 11:46 AM, Ralf Wildenhues wrote:


Hello Benoit,

* Benoit SIGOURE wrote on Sat, Oct 20, 2007 at 01:58:23PM CEST:

Hello list,
Due to a sudden lack of imagination, I wrote a testsuite named  
`check' and
used it as a `check_SCRIPTS' which led to an infinite recursion of  
make

(because the .PHONY check depends on check-am which does a `$(MAKE)
$(AM_MAKEFLAGS) $(check_SCRIPTS)' so the make has no chance of  
catching the

dependency cycle).

Maybe automake should warn (or bail out) in such a case.  I can  
write a

patch for that, if you think that could be something relevant.


Well, the user should be able to override the `check' target if he so
wants.  If it's possible to reliably warn without giving false  
failures

without a lot of work, then it would help.  But often such checks turn
out to be rather expensive in both developer time and automake run  
time.


When you put `check' in `check_SCRIPTS' you're not directly willing  
to override the `check' target.  `check' can happen to be generated,  
or it may not.  I think it would be relevant to warn users that  
putting `check' in `check_SCRIPTS' can lead to infinite make  
recursion, and mention that in the docs.



Maybe something along these lines would be better:
diff --git a/automake.in b/automake.in
index 3c47cc1..263674c 100755
--- a/automake.in
+++ b/automake.in
@@ -6826,8 +6826,10 @@ sub am_primary_prefixes ($$@)
 # Handle `where_HOW' variable magic.  Does all lookups, generates
 # install code, and possibly generates code to define the primary
-# variable.  The first argument is the name of the .am file to  
munge,
-# the second argument is the primary variable (e.g. HEADERS), and  
all
+# variable.  The first argument can be one of: '-noextra', '- 
candist',

+# or '-defaultdist'.  FIXME: Document these options.
+# The following argument is the name of the .am file to munge,
+# the following argument is the primary variable (e.g. HEADERS),  
and all

 # subsequent arguments are possible installation locations.


Sorry, but I don't understand at all what you're trying to say here.


Hmm sorry, it's just that the documentation of that function doesn't  
mention that the first argument can be an option such as '-candist'  
and it disturbed me when wandering through the code, somehow.


--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory




PGP.sig
Description: This is a digitally signed message part

Re: Infinite recursion with `check_SCRIPTS = check'

[Ralf Wildenhues]

Hello Benoit,

* Benoit SIGOURE wrote on Sun, Oct 21, 2007 at 04:00:42PM CEST:
> On Oct 21, 2007, at 11:46 AM, Ralf Wildenhues wrote:
>>
>> Well, the user should be able to override the `check' target if he so
>> wants.  If it's possible to reliably warn without giving false failures
>> without a lot of work, then it would help.  But often such checks turn
>> out to be rather expensive in both developer time and automake run time.
>
> When you put `check' in `check_SCRIPTS' you're not directly willing to 
> override the `check' target.  `check' can happen to be generated, or it may 
> not.  I think it would be relevant to warn users that putting `check' in 
> `check_SCRIPTS' can lead to infinite make recursion, and mention that in 
> the docs.

Sure, feel free to submit a patch (to automake-patches).

>>> Maybe something along these lines would be better:
[...]
>>> @@ -6826,8 +6826,10 @@ sub am_primary_prefixes ($$@)
>>>  # Handle `where_HOW' variable magic.  Does all lookups, generates
>>>  # install code, and possibly generates code to define the primary
>>> -# variable.  The first argument is the name of the .am file to munge,
>>> -# the second argument is the primary variable (e.g. HEADERS), and all
>>> +# variable.  The first argument can be one of: '-noextra', '-candist',
>>> +# or '-defaultdist'.  FIXME: Document these options.
>>> +# The following argument is the name of the .am file to munge,
>>> +# the following argument is the primary variable (e.g. HEADERS), and all
>>>  # subsequent arguments are possible installation locations.
>>
>> Sorry, but I don't understand at all what you're trying to say here.
>
> Hmm sorry, it's just that the documentation of that function doesn't 
> mention that the first argument can be an option such as '-candist' and it 
> disturbed me when wandering through the code, somehow.

Ah, ok.  I failed to grasp that your proposed patch had no relevance to
the infinite recursion (other than the fact that you happened to stumble
upon it at the same time ;-).  Well, I'd prefer the function
documentation to be addressed in a separate patch, and I'd even more
prefer if the patch reduced the number of FIXMEs instead of increasing
it.  :-)

Cheers,
Ralf

-pipe passed to gcc via Automake

[NightStrike]

If I wanted -pipe passed in to gcc all the time, do I put that in
AM_CPPFLAGS or AM_CFLAGS?

Re: Makefile.am assistance

[NightStrike]

On 10/21/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Fri, Oct 19, 2007 at 09:25:08PM CEST:
> >
> > crt_SCRIPTS = libcrtdll.a libmsvcrt.a libmsvcr80.a
> > libcrtdll.a libmsvcrt.a libmsvcr80.a:
> > base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
> > $(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
> > $(top_srcdir)/$${base}.def
> >
> > To generate those three libraries, I do nothing other than run
> > dlltool, passing in the appropriate .def file.
>
> Let's deal with one library only.  For the moment, leave Automake out of
> the picture, this is a mere issue of how to write 'make' rules.

> Am I right in that the input files to dlltool in this case are
> foo.dll and foo.def, and the output is the import library libfoo.a?

Sort of.  foo.dll is not an actual file.

> Then write
>   libfoo.a: foo.dll foo.def
> rule...
>
> for each library.  If you can require GNU make (which I guess you can),
> then you can write one pattern rule
>   lib%.a: %.dll %.def
> rule...

I sort of did that for the very very long list of .a libs appended to
crt_DATA.  I wrote this further down in the makefile:

lib%.a:
$(DLLTOOL) $(DLLOPTS) --def $(top_srcdir)/lib/$*.def

But I didn't know how to adapt that for the extra command to dlltool,
which is '--dllname=foo.dll'

So what I did was the following (committed it as revision 151, too, so
you can see it in the svn repository) :
Index: Makefile.am
===
--- Makefile.am (revision 151)
+++ Makefile.am (working copy)
@@ -36,9 +36,13 @@ dllcrt1.o:
 dllcrt2.o:
$(COMPILE) -c $(top_srcdir)/crtdll.c -o $@ -D__MSVCRT__ -U__CRTDLL__

-libcrtdll.a libmsvcrt.a libmsvcr80.a:
-   base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
-   $(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
$(top_srcdir)/$${base}.def
+#libcrtdll.a libmsvcrt.a libmsvcr80.a:
+#  base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
+#  $(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
$(top_srcdir)/$${base}.def
+
+lib%.a: %.def
+   $(DLLTOOL) $(DLLOPTS) --dllname $*.dll --def=$(top_srcdir)/$*.def
+
 #libcrtdll.a:
 #  $(DLLTOOL) --as=$(AS) -k --dllname crtdll.dll --output-lib $@
--def $(top_srcdir)/crtdll.def
 #libmsvcrt.a:


Now, however, I have two rules called lib%.a that do different things.
 Somehow, make is getting it right, but I have no idea why.

> > Do you know how to achieve the above effect with using the _LIBRARIES
> > primary instead of overriding the use of _SCRIPTS?
>
> Well, I could tell you that Libtool can create DLLs plus import
> libraries (it names them libfoo.dll.a), but I don't think you want
> to hear that at this point.  ;-)

I'd love to hear about it.  If libtool can do this better, then I'll
use it.  I must confess, though, that I couldn't figure it out.  It
seemed to require foo.la as output libs instead of foo.a.

Re: -pipe passed to gcc via Automake

[Ralf Wildenhues]

Hello whoever(?),

* NightStrike wrote on Sun, Oct 21, 2007 at 07:13:19PM CEST:
> If I wanted -pipe passed in to gcc all the time, do I put that in
> AM_CPPFLAGS or AM_CFLAGS?

You pass it to configure via CFLAGS, or CC:
  ./configure CC='gcc -pipe'

It makes not much sense in *CPPFLAGS: can't it help the assembly stage,
too?  Neither does it make sense for you, the developer, to put it in
AM_*, because the user may want to use a compiler different from gcc.
If you know gcc will be used, then AM_CFLAGS should be fine.

Cheers,
Ralf

Re: -pipe passed to gcc via Automake

[Benoit SIGOURE]

On Oct 21, 2007, at 7:13 PM, NightStrike wrote:


If I wanted -pipe passed in to gcc all the time, do I put that in
AM_CPPFLAGS or AM_CFLAGS?


I usually do this in my configure.ac:

AC_PROG_CXX
# Speed GCC compilation up.
if test "$GXX" = yes; then
  CXXFLAGS="$CXXFLAGS -pipe"
fi

-or-

AC_PROG_CC
# Speed GCC compilation up.
if test "$GCC" = yes; then
  CFLAGS="$CFLAGS -pipe"
fi

(the $GCC and $GXX variables are set by AC_PROG_{CC,CXX})
Cheers,

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory




PGP.sig
Description: This is a digitally signed message part

Re: -pipe passed to gcc via Automake

[Harlan Stenn]

Benoit wrote:
> I usually do this in my configure.ac:
> 
> AC_PROG_CXX
> # Speed GCC compilation up.
> if test "$GXX" = yes; then
>CXXFLAGS="$CXXFLAGS -pipe"
> fi

I use case statements wherever possible instead of 'test'.

While 'case' is a shell builtin, 'test' may not be.  If there are a
bunch of checks being done, it can be significantly faster to use 'case'
instead of 'test'.

Disclaimer: I have been doing this for Years (I picked it up from Larry
Wall sometime before I took over the maintenance of metaconfig) and have
not tested it lately.

H

Re: -pipe passed to gcc via Automake

[Bob Friesenhahn]

On Sun, 21 Oct 2007, Benoit SIGOURE wrote:


On Oct 21, 2007, at 7:13 PM, NightStrike wrote:


If I wanted -pipe passed in to gcc all the time, do I put that in
AM_CPPFLAGS or AM_CFLAGS?


I usually do this in my configure.ac:

AC_PROG_CXX
# Speed GCC compilation up.
if test "$GXX" = yes; then
 CXXFLAGS="$CXXFLAGS -pipe"
fi


Sounds great, but I have yet to see -pipe actually speed up 
compilation.  It would only really help if the temporary file 
directory was remarkably slow or perhaps somehow the user is not 
allowed to write temporary files.  It is true that GCC's temporary 
files may be large, but it is also true that pipes only offer limited 
buffering and two programs must execute at once (requiring context 
switching) rather than just one at a time.


Sometimes pipes may not be supported.  In that case hopefully GCC 
simply ignores the request rather than refusing to run.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: -pipe passed to gcc via Automake

[Benoit SIGOURE]

On Oct 21, 2007, at 11:24 PM, Bob Friesenhahn wrote:


On Sun, 21 Oct 2007, Benoit SIGOURE wrote:


On Oct 21, 2007, at 7:13 PM, NightStrike wrote:


If I wanted -pipe passed in to gcc all the time, do I put that in
AM_CPPFLAGS or AM_CFLAGS?


I usually do this in my configure.ac:

AC_PROG_CXX
# Speed GCC compilation up.
if test "$GXX" = yes; then
 CXXFLAGS="$CXXFLAGS -pipe"
fi


Sounds great, but I have yet to see -pipe actually speed up  
compilation.  It would only really help if the temporary file  
directory was remarkably slow or perhaps somehow the user is not  
allowed to write temporary files.  It is true that GCC's temporary  
files may be large, but it is also true that pipes only offer  
limited buffering and two programs must execute at once (requiring  
context switching) rather than just one at a time.


Sometimes pipes may not be supported.  In that case hopefully GCC  
simply ignores the request rather than refusing to run.


Hmm indeed, I tested a `make clean all' (with ccache disabled and  
all) on a project with ~18k lines of code (sloccount) and the build  
without `-pipe' was 6s "faster".  So yeah, I doubt that -pipe speeds  
anything up.


Thanks!

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory




PGP.sig
Description: This is a digitally signed message part

Re: Makefile.am assistance

[Brian Dessent]

Ralf Wildenhues wrote:

> Well, I could tell you that Libtool can create DLLs plus import
> libraries (it names them libfoo.dll.a), but I don't think you want
> to hear that at this point.  ;-)

Libtool isn't appropriate here because he's not actually building any
libraries, only synthesizing import libraries from a .def file for
existing binary Microsoft .DLLs.

Brian

Re: -pipe passed to gcc via Automake

[Ralf Corsepius]

On Sun, 2007-10-21 at 16:24 -0500, Bob Friesenhahn wrote:
> On Sun, 21 Oct 2007, Benoit SIGOURE wrote:
> 
> > On Oct 21, 2007, at 7:13 PM, NightStrike wrote:
> >
> >> If I wanted -pipe passed in to gcc all the time, do I put that in
> >> AM_CPPFLAGS or AM_CFLAGS?
> >
> > I usually do this in my configure.ac:
> >
> > AC_PROG_CXX
> > # Speed GCC compilation up.
> > if test "$GXX" = yes; then
> >  CXXFLAGS="$CXXFLAGS -pipe"
> > fi
> 
> Sounds great, but I have yet to see -pipe actually speed up 
> compilation. 
I performed some measurements several years ago - It really does speed
up compilation.

But ... IMO, such tricks should be left to the user and do not belong
into configure.ac

Also, you really want to append it to CC and not to CPPFLAGS, because
--pipe is not a cpp option.

> Sometimes pipes may not be supported.  In that case hopefully GCC 
> simply ignores the request rather than refusing to run.
... very old GCCs (<< 3.x) don't support it.

Ralf