Re: Proper location to install shell function libraries?

[Ralf Corsepius]

On 03/02/2017 05:57 AM, Basin Ilya wrote:

I agree. Consider RHEL/CentOS where you can simultanneously install both .i686 
and .x86_64 versions of one package. The packages are allowed to have 
overlapping files, if these files don't differ.

If one puts script libraries to $libdir/,  CentOS will have duplicate files in 
/lib/ and /lib64/, but in case of $datadir there will be only one 
/usr/share/


Right, but this is only applicable if all files are arch-independent and 
guaranteed to stay so for ever.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Proper location to install shell function libraries?

[Ralf Corsepius]

On 03/01/2017 05:13 PM, Nick Bowler wrote:


The definition of these install variables comes from the GNU Coding
Standards[1].  You mention the installed scripts are machine-dependent
so they should be installed in either libdir or libexecdir.  GCS says:

  "libexecdir: The directory for installing executable programs to be
   run by other programs rather than by users  ..."

>

  "libdir: The directory for object files and libraries of object
   code ..."

Which doesn't really help us decide where to install non-executable
machine-dependent shell fragments.


Note the term "executable programs" in the section on "libexecdir", you 
cited above. Shell fragment usually aren't "executable".



Based on this information alone,
libexecdir seems like a reasonable choice.  However, looking at what
packages installed on my computer do, libdir seems to be much more
commonly used.

This observation has its reasons (at least under Linux).

- Many distros do not support or did not support libexecdir and favor 
$libdir/.

- Many packages do not use libexecdir.
- Putting everything into $libdir/ is easier to use.

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Proper location to install shell function libraries?

[Ralf Corsepius]

On 03/01/2017 02:35 PM, Andreas Kusalananda Kähäri wrote:


My query is this: Would libexecdir be the best place to put a file that
is architecture dependent, but *not* meant to be executed separatedly
(it's a library).  Or should it actually be stored under libdir


$libexecdir is meant to take a suite's/package's 
"internal/sub-programs/executables/scripts" (typically with executable 
permissions). Think of it as a auxiliary $bindir, which is supposed not 
to be in $PATH.


$libdir// (e.g. %libdir/) is the playground a package 
can install more or less whatever it wants, comprising executables.


As your "scripts" don't seem to be "programs", $libdir/ probably 
is what you are looking for.


> (which
> I've never seen done with a shell library of functions)?
Storing script fragments or scripts in $libdir would be unusual and 
discussworthy, but installing these to $libdir// is quite common.


Ralf




___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: autocon and sub-packages

[Ralf Corsepius]

On 09/04/2015 02:26 PM, Sébastien Hinderer wrote:


Eric Blake (2015/09/04 06:07 -0600):

On 09/03/2015 08:09 AM, Sébastien Hinderer wrote:

Dear all,

I am one of the maintainers of Coccinelle[1], a tool written in the
Objective Caml[2] language.

The tool is distributed with the libraries it depends on (they are
provided as bundles).



Camllanguage and its libraries are not as widespread as gettext and
libtool. So the idea of the bundles is tomake life of end-users simpler,
but of course it also makes thelifeofdevelopers and maintainers a bit
harder.


Well, what I can tell you with my Fedora on is that in Fedora we 
discourage bundling, because it in a nutshell raises a lot problems in 
maintenance, both for system-integrators (read: distros) and upstreams.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Bash security issue

[Ralf Corsepius]

On 09/29/2014 03:13 PM, Eric Blake wrote:

On 09/29/2014 05:19 AM, Ralf Corsepius wrote:

On 09/25/2014 05:53 PM, Eric Blake wrote:


Huh? There is no wasted effort in teaching configure scripts to warn
users that they are running on an unpatched vulnerable system.  Just
because a fix may be available doesn't mean everyone is running the fix.


I do not see any sense in this at all, unless the bash bug itself would
impact configure scripts themselves.


But it MIGHT impact configure scripts.  One of the goals of configure is
to 'export' variables into the build environment prior to calling
config.status recipes.

Yes, but only those which are relevant. Not any arbitrary ones.


The whole point of the Shell Shock bug is that
there are some values that you cannot safely export, because doing so
risks your child misbehaving.  As we cannot predict which child
processes will be run during config.status, configure scripts may indeed
be vulnerable.

Do you have proof or is this just paranoia/hysteria?

I am inclined to believe your action to be "hyperactivity" addressing a 
temporary issue, which soon will be non important but be carried around 
ad infinitum until nobody recalls the origin. It also won't help the 
1000s of existing generated configure scripts.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Bash security issue

[Ralf Corsepius]

On 09/25/2014 05:53 PM, Eric Blake wrote:


Huh? There is no wasted effort in teaching configure scripts to warn
users that they are running on an unpatched vulnerable system.  Just
because a fix may be available doesn't mean everyone is running the fix.


I do not see any sense in this at all, unless the bash bug itself would 
impact configure scripts themselves.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: How to include macro headers

[Ralf Corsepius]

On 06/24/2014 03:06 PM, Praveen kumar R wrote:

Hi All,
I have a generic inc file where all the build macros are present.
These macros are used in the source c files to make switches, how can I
include this inc file in autoconf.
I tried using "include" directive in my am file and it does not have any
effect.


Try adding such files to *_SOURCES.

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: machine-dependent header installation path

[Ralf Corsepius]

On 05/18/2014 01:18 PM, Thomas Klausner wrote:

Hi!

I'm co-developing libzip (www.nih.at/libzip). During configury, the
library detects types of sizes 8, 16, 32 and defines zip_{u,}intX_t
dependent on that, which is then used in all places that need fixed
sized integers.

These defines are saved in a file "zipconf.h" which is used by the
installed zip.h header file.

I remember reading years ago that such machine-dependent header files
should not be installed in include/, but below lib/, so that include/
can be shared between all kinds of machines. That's the reason
zipconf.h is currently installed into
$PREFIX/lib/libzip/include/zipconf.h. A pkg-config file helps users
find the library headers.

Ok, long story short: users are asking why we're installing in this
"weird" path, and I couldn't find the rationale I was remembering any
longer. Can you someone point me to it?


To cut a long story short: In a multilib'ed compilation environment all 
files below /usr/include must be identical on all architectures.



Or do I misremember or had misunderstood something? If so, what are
the current best practices for where to install such a header file?
${libdir}// is a perfectly suitable choice, because in a 
multilib'ed environment, ${libdir} is architecture-dependent.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: configure speedup proposal: add --assume-c99 and --assume-posix2008 flags

[Ralf Corsepius]

On 03/23/2014 01:24 AM, John Spencer wrote:

there are many configure scripts out there that still check for things
that are standard since at least 10 years, and doing this extensively
and over and over (people building software themselves usually build
more than one package) consumes a lot of time (especially due to the
non-parallel nature of configure scripts).
often configure scripts take longer to finish than compiling the source
code itself on decent machines with multiple cpu cores.

having an option like --assume-c99 could provide a shortcut so all
checks like

- have stdint.h
- have snprintf()
- etc

and for posix
- sizeof int == 4
- have select()
- etc


These assumptions are unsafe, esp. on non-mainstream architectures/OSes, 
which only partially implement c99.


E.g. it's not that uncommon to find toolchains for embedded platforms 
which implement most of C99, but with sizeof int != 4 or without "select()".


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: How to use PREFIX created by autoconf in source file

[Ralf Corsepius]

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 mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: How to use PREFIX created by autoconf in source file

[Ralf Corsepius]

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
installed. In plain Makefile, it could be done like

gcc -DPREFIX "/usr/share"

and in the source file, data path is generated in

#define DATAPATH PREFIX "/data"

with autoconf, how could I use the path specified by --prefix in source
code? Is there a pre-defined MACRO for this?

Autoconf has no business in handling Makefiles.

I.e. the answer to your question depends upon your way to propagate 
autoconf variables to your Makefile-system.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

[Ralf Corsepius]

On 05/15/2013 06:13 PM, Mike Frysinger wrote:

On Wednesday 15 May 2013 09:54:08 Ralf Corsepius wrote:

On 05/15/2013 05:53 AM, Mike Frysinger wrote:

On Monday 08 October 2012 08:46:57 Paul Wise wrote:

So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below). We could
patch every single package that contains config.guess and config.sub but
that would be a lot of effort that doesn't scale. We could also patch
our build tools but the problem would still exist for other distros.

yes, Gentoo fixed this for every package in our tree like 9 years ago (we
added a common function like 11 years ago that ebuilds could call
manually, but we found that didn't scale).  when you run a standard
autoconf script, we automatically search for files named "config.sub"
and "config.guess" and replace them with the up-to-date host copy.  no
checking or anything :).  in hindsight, that seems like a bad idea, but
in practice, i think we have yet to find a package that this doesn't
actually work.

Well, I can't imagine a case affecting config.guess, but constructing
cases affecting config.sub is pretty simple.

Classical use-case is developing on cross-built packages, which require
a new host/target-tuple and therefore ship a customized/modified
config.sub.

i take the stance that if you haven't merged your code into the GNU config
project, then you deserve to break.
Well, config.sub has allways been amongst those files the autotools 
supposed not to be generated.


That said, if you replace them by brute-force, you are breaking the UI 
of the autotools - Read: an utterly bad idea. RH/Fedora has done this 
for a very long time and has given up doing so for several years, and 
now is relying on packagers explicitly replacing them (autoreconf -f 
rsp. by patching).


A better approach would be to only replace them, if they you are sure, 
they are unmodified.



   or at least, you're too bleeding edge to
be merged into mainline Gentoo (which, honestly, is saying something).



Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

[Ralf Corsepius]

On 05/15/2013 05:53 AM, Mike Frysinger wrote:

On Monday 08 October 2012 08:46:57 Paul Wise wrote:

So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below). We could
patch every single package that contains config.guess and config.sub but
that would be a lot of effort that doesn't scale. We could also patch
our build tools but the problem would still exist for other distros.


yes, Gentoo fixed this for every package in our tree like 9 years ago (we added
a common function like 11 years ago that ebuilds could call manually, but we
found that didn't scale).  when you run a standard autoconf script, we
automatically search for files named "config.sub" and "config.guess" and replace
them with the up-to-date host copy.  no checking or anything :).  in
hindsight, that seems like a bad idea, but in practice, i think we have yet to
find a package that this doesn't actually work.
Well, I can't imagine a case affecting config.guess, but constructing 
cases affecting config.sub is pretty simple.


Classical use-case is developing on cross-built packages, which require 
a new host/target-tuple and therefore ship a customized/modified config.sub.


Those cases are rare in publicly available/released packages, but they 
are not uncommon in the toolchain/OS developer's community. Think about 
working on "cfin-MikeOS" toolchain in binutils/gcc/gdb or adding support 
for it to other auto*tools-based package ;)


At least for RTEMS, we had once carried such a customized config.sub for 
a short period time.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Autoconf does not like "-D_FORTIFY_SOURCE=2 -O2"

[Ralf Corsepius]

On 05/08/2013 04:00 PM, Zack Weinberg wrote:

On Wed, May 8, 2013 at 1:17 AM, Allan McRae  wrote:

Our distribution packages are compiled with:

CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4"

So when both CPPFLAGS and CFLAGS are passed there is no issue.


I think the quick fix from your end is to move -D_FORTIFY_SOURCE to
CFLAGS (and presumably also CXXFLAGS).


FWIW: This is what Fedora and RH are doing for years.

Ralf

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Cross-platform availability of header files

[Ralf Corsepius]

On 03/15/2013 09:13 PM, Zack Weinberg wrote:

On 2013-03-15 8:57 AM, Ralf Corsepius wrote:


aio.h and sys/mman.h are not available everywhere


aio.h certainly, but are you aware of a *specific Unix-like system*
which is in current use and does not provide ?

Unix-like! Not all OSes are Unix-like.

Most prominent one without mman.h is mingw. Others, I am aware about are 
certain newlib based toolchains.


Newlib also is one of the places which has a history of struggling with 
the _POSIX_*-defines (Also affects Cygwin).



That header
is mandatory in POSIX-2008 (although not before then) and the last time
I can remember encountering a workstation-scale Unix environment that
didn't have it was in the mid-nineties sometime.  I'd believe there
might be embedded mostly-POSIX-compliant environments still that don't
do virtual memory, but I've never seen one.
Correct - RTEMS is one of these. We have a rudimentary implementation of 
aio.h since 2010 and don't have mmap.h at all.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Cross-platform availability of header files

[Ralf Corsepius]

On 03/15/2013 11:13 AM, Thomas Jahns wrote:

On 03/15/2013 02:19 AM, Zack Weinberg wrote:

I've been doing research into the cross-platform availability of
header files that are commonly probed for in Autoconf scripts.
Results so far are here:
http://www.owlfolio.org/possibly-useful/notes-on-the-cross-platform-availability-of-header-files/
  Based on what I've learned, I have some questions for y'all:


although you didn't ask: aio.h does not need to be probed for: unistd.h defines
_POSIX_ASYNCHRONOUS_IO when it's available.

See  for
some other features that don't require autoconf to check for, sys/mman.h is in
the same category.


This is the description of an ideal world - Reality is a bit different.

aio.h and sys/mman.h are not available everywhere, nor are the _POSIX_* 
defines always correct, nor are the features these are supposed to 
provide available everywhere.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: How to NOT include ($CFLAGS) in LINK?

[Ralf Corsepius]

On 03/01/2013 09:25 AM, Vania Joloboff wrote:

We have exactly the same problem

We want to compile code with CFLAGS = -march=armv5t -mthumb
-mthumb-interwork

but we do not want to link with these options because they actually produce
a different executable that we do not want

We want to have only AM_LDFLAGS and LDFLAGS when linking, not CFLAGS

This means, your toolchain is broken or your CFLAGS are wrong.


What do we do ?

Likely something CFLAGS=-Wl, or similar could work.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [RFC] pass #2 at getting rid of the config.guess/sub problem when bootstrapping new ports/systems

[Ralf Corsepius]

On 10/09/2012 05:27 AM, Paul Wise wrote:

On Mon, 2012-10-08 at 20:46 +0800, Paul Wise wrote:


>So, Debian is in the process of bringing up our upcoming arm64 port.
>Unfortunately we are also coming across lots of packages with rather
>outdated config.guess and config.sub files (see links below).

I've taken on board advice received during this thread and elsewhere and
updated the patch to always use the latest config.guess and config.sub
files. I've also tested the result on one of the things I'm upstream for
and it works to my satisfaction. The only downside is that there is a
code block that occurs twice in each generated configure script, but I'm
not sure how to avoid that, any pointers? Please see the attached patch.


I don't like this approach, because I think you are missing that 
config.sub and config.guess have only been overwritten as part of 
"autoreconf -f" (and not of "autoreconf"). This allows package upstreams 
to implement customized versions of both of these scripts.


Though such cases are rare to find in mainstream packages, theses case 
are quite common in cases to toolchain/OS implementors and 
cross-compilation scenarios.



FWIW: Apart of this, in comparable situations in the past, on Red Hat 
based distros, IIRC, RedHat had chosen to copy their versions of 
config.guess+config.sub as part of their build-process [1] by
default[2]. This would be comparable to the dh_ others 
mentioned before in this thread.


Ralf

[1] This copying operation was part of rpm's %configure.
Meanwhile, Red Hat/Fedora relies on packages to providing suitable 
config.{guess,sub}s themselves, i.e. either "suiteable versions", or 
"autoreconf -f" or patching.


[2] I.e. there were ways to allow packages to use their own
config.{guess,sub}.

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Problems Configuring (C Compiler cannot produce executables)

[Ralf Corsepius]

On 08/23/2012 09:14 AM, Miles Bader wrote:

Russ Allbery  writes:

Also, you should generally not add -Wall -Wextra to the configure flags,
and instead add it after configure completes, since many of the tricks
configure has to use will result in warnings when you turn on all the
compiler warnings, which can confuse configure.


How can that confuse configure?


No idea. The working priciples of standard autoconf checks are based on 
evaluating compiler errors only and to ignore warnings[1], therefore 
-Wall -Wextra must not desturb "by definition".


However, adding -Werror to CFLAGS is dangerous, because this will raise 
GCC warnings to errors, which will cause autoconf to become confused and 
to produce bogus results.


Ralf

[1] There exist (non-standard) autoconf checks which are based on 
evaluating compiler warnings. If properly written, these also should not 
be affected by "-Wall -Wextra", ... if they are, these checks need to be 
considered broken ;)



___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: How can I enable option-checking from configure.ac after it being default-disabled?

[Ralf Corsepius]

On 03/19/2012 04:16 PM, Eric Blake wrote:


Meta-question: Why are you disabling option-checking in the first place?
  It's contrary to GNU Coding Standards (the ability to disable option
checking is provided for non-GNU packages, but doesn't get as much
testing because GNU packages shouldn't be using it in the first place).


Option checking presumes all config-subdirs configure scripts are 
accepting the same set of configure-options.


This doesn't always apply and even less applies in cases of optional 
config-subdirs, esp. in cases when config-subdirs originate from 
different origins and are being treated as optional drop-in packages.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Search for an header file in different paths

[Ralf Corsepius]

On 10/18/2011 04:26 PM, Alessandro Candini wrote:


Before upgrading my Ubuntu linux to 11.10 version, I had gdal.h under
/usr/local/include: configure and make succeed without errors.
Now I have it under /usr/include/gdal and I get that gdal.h cannot be
found (in my source files there is a simple "#include ").


/configure CPPFLAGS=-I/usr/include/gdal


How can I manage the two cases in the same configure.ac: system in which
gdal.h is in /usr/include and others in which it is in /usr/local/include?


c.f. above. Leave passing include-paths to your users. Only he knows 
(rsp. he is supposed to know) where a package's headers are installed.


A package's author can't know where his package's users may have 
installed the package's headers into.


Ralf

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: AM_PROG_UPC

[Ralf Corsepius]

On 04/30/2011 01:16 AM, Too, Justin A. wrote:

Hi all,

In my configure.ac I simply invoke: AC_PROG_UPC

…
$ aclocal …
 aclocal:configure.ac:12: warning: macro `AM_PROG_UPC' not found in library
…
$ autoconf
 Configure.ac:12: error: possibly undefined macro: AM_PROG_UPC
If this token and others are legitimate, please use m4patternallow.
See the Autoconf documentation.

Is this a non-standard macro?

Yes.

[Apart of this, AM_PROG_UPC violates auto*tools naming conventions; 
AM_*/AM_* prefixed macros are reserved for autoconf rsp. automake.]



Then, how can I add UPC support to my Autotools project?
Non-standard macros need to be supplied by either the package itself or 
by other packages.


There are several ways to do so, so answering your question would 
require knowing more details about the package you are trying to build.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Multiple subdirectories with non-similar configure needs

[Ralf Corsepius]

On 03/29/2011 06:39 PM, Stefano Lattarini wrote:

Hello autoconfers. Just my 2 cents about the issue ...



Do you think it would be viable/useful to enahnace AC_CONFIG_SUBDIRS (or
write a brand new macro) to allow the "parent" configure script to pass
different options to different "sub" configure scripts?  I know one can
use the `configure.gnu' hack, but that does not seem clear or natural as
using e.g.:
   AC_CONFIG_SUBDIRS([foo], [--with-zardoz])
   AC_CONFIG_SUBDIRS([bar], [--without-zardoz])


It's a step into the right direction. It is useful in cases when you 
only want to append arguments (which often applies).


However, in general, you will want to process a configure script 
arguments and to compose the arguments to pass to sub-configure scripts.


Also to be taken into account in such a context would be autoconf's 
"precious vars" and config.caches (They both only work if a 
sub-configure's precious vars and config.cache'ed vars's notion matches).


When generalizing more, there are cases a user wants to create build 
subdirs dynamically. Classical use case for this would be a 
cross-compiled package suite containing "build"/"host" and (several) 
target compiled subdirs. Another use-case would be users wanting to 
compile the same subdir multiple times.


Ralf

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: configure.ac vs configure.in

[Ralf Corsepius]

On 02/11/2011 07:23 AM, Reuben Hawkins wrote:

Hi,

Which version introduced configure.ac?

It was gradually introduced during the autoconf-2.49/2.50 phase,
ca. 10 years ago.


Is configure.in deprecated?
De-facto yes. The official nomenclature being used is "configure.ac is 
preferred".



 If so,
was it deprecated in the same version that introduced configure.ac?

Yes.

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Paralizing configure

[Ralf Corsepius]

On 02/09/2011 05:03 AM, Miles Bader wrote:

Marian Marinov  writes:

We can start a new branch and see if it is worth the work. And if it is ok we
can then start the upgrade of all the code.

I'm sure that there would be situations in which the tests must remain
sequental. However we can isolate them into bigger independent sections of
tests.


At the least, constructs like
AC_CHECK_HEADERS([stdint.h unistd.h fcntl.h sys/mman.h sys/stat.h])
could check all the entries in parallel.


Only simple scenarios, in which headers and header search paths are 
static - This often doesn't apply to complex configurations.


Ralf

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: configure -C by default?

[Ralf Corsepius]

On 02/07/2011 11:35 AM, Peter Breitenlohner wrote:

On Mon, 7 Feb 2011, Ralf Corsepius wrote:

The only real world use-case I currently have for config.caches, is 
it being a offering a crude way to override configure settings when 
configure guesses things wrong (A real-world use case: Paths to tools 
when cross-building scripts)


My real world use-case is TeX live with a total of about 70 configure
scripts and a very large number of common tests.  Here -C gives a
considerable speed-up with prcatically no problems.

Quite possible, ... when things are designed to apply config.cache.

In many cases this does not apply. Also consider that many "modern" 
autoconf/aclocal-m4-macros (those not being part of autoconf or 
automake) do not honor config.caches.




Thus I'd certainly object to a removal of the cache file.

Not much of a problem - Making "configure -C default" to me is not helpful.

BTW, IIRC - and correct me if I am wrong, it used to be default and was 
removed around the time frame of the discussions Ralf W. cited.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: configure -C by default?

[Ralf Corsepius]

On 02/07/2011 10:02 AM, Peter Rosin wrote:

Den 2011-02-07 09:14 skrev Ralf Corsepius:

Provided how HW has developed since the discussions from 10 years
ago, you cited about, I am actually leaning towards proposing the
converse of your proposal: Autoconf toconsider to abandoning
config.cache.

No, it still needs to be optional.
I don't have anything against this. However, it's simply that the 
overwhelming majority of current packages hasn't been developed with 
config.caches in mind. And of those which really use it (complex 
packages such as GCC or GDB) occasionally to get things wrong. So, IMO, 
the advantage you believe to see on cygwin or mingw is of limited benefit.



  Not everybody have the luxury
of running on the bare OS.  E.g. Cygwin is not very fast at
running configure and that matters a lot for me since I have a
number of packages with checks for about the same things and they
benefit *very* much from sharing the cache.

:=)

The only real world use-case I currently have for config.caches, is it 
being a offering a crude way to override configure settings when 
configure guesses things wrong (A real-world use case: Paths to tools 
when cross-building scripts)


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: configure -C by default?

[Ralf Corsepius]

On 02/06/2011 11:11 PM, Ralf Wildenhues wrote:

Apparently, a lot of users do not even know about configure -C aka.
--config-cache which of course doesn't help Autoconf's reputation about
producing configure scripts which are slow even for development.

So one question would be what about making -C the default?

I am opposed to it.


We could have --force or --no-cache to turn it off.



This behavior actually used to be the default.  It was reverted around
commit 5ae14bc8c048ed9a2dda6b67794ba (and also see
commit 4abad4e9bfbcedd018302059844f8), 10 years ago.

Here's some discussion from back then, listed in the order in which I
traced back things, that is, the last thread has the most info:

http://sourceware.org/ml/autoconf-patches/2000-04/msg0.html
http://sourceware.org/ml/autoconf-patches/2000-03/msg00274.html
http://sourceware.org/ml/autoconf/2000-02/msg00271.html

Back then, the consensus was to not make it the default because that was
deemed too dangerous for users.

IMO, all what had been said 10+ years ago still applies.

Besides that, config.caches only provide real advantages to "complex 
packages", but do not provide many advantages to "occasional autoconf 
users".



Various reports are cited, and also the
problem is mentioned that such kinds of failures tend to be quiet very
often and are hard to debug.

Correct.

Even experienced people, who believe have understood config.caches and 
who actively take them into account during their works (Most users 
don't), often make mistakes related to them.



Comments are appreciated.

Please don't go this road. Config.caches should remain optional.

Provided how HW has developed since the discussions from 10 years ago, 
you cited about, I am actually leaning towards proposing the converse of 
your proposal: Autoconf to  consider to abandoning config.cache.


Ralf

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: configure -C by default?

[Ralf Corsepius]

On 02/07/2011 12:39 PM, Peter Rosin wrote:

Den 2011-02-07 11:12 skrev Ralf Corsepius:

On 02/07/2011 10:02 AM, Peter Rosin wrote:

Den 2011-02-07 09:14 skrev Ralf Corsepius:

Provided how HW has developed since the discussions from 10 years
ago, you cited about, I am actually leaning towards proposing the
converse of your proposal: Autoconf toconsider to abandoning
config.cache.

No, it still needs to be optional.

I don't have anything against this. However, it's simply that the
overwhelming majority of current packages hasn't been developed
with config.caches in mind. And of those which really use it
(complex packages such as GCC or GDB) occasionally to get things
wrong. So, IMO, the advantage you believe to see on cygwin or mingw
is of limited benefit.

What do you mean by "believe to see" and "of limited benefit"?
When you apply config.caches across packages, there is no guarantee that 
the values stored in a config.cache have the same semantics/meaning.


I.e. when  trying to share config.caches between packages (esp. 
independently developed ones),

* you are at risk of _silently_ miscompiling something.
* not to gain much, because a configure-script doesn't not honor 
config.caches (Pretty typical for "modern" configure script using 
non-standard macros).


These were the aspects I was referring to.


You are apparently not getting it, or you are downplaying my use case
deliberately.
Neither - I am using autoconf for many, many years and am well aware 
about the benefits config.cache can have, when _carefully_ being used.


However, in contemporary development on todays, I've rare experienced 
config-caches to be more of a nuissance but to be of real advantage.



  The advantage I see for the packages I care about and
regularly work on is very real: the experience moves from the "pain in
the ass" category to "bearable" when I enable the cache.

I'm not talking about one-time builds on Cygwin, I talking about doing
development there.

Well, I would not want to use Cygwin ;)

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: HAVE_STDBOOL_H, AC_HEADER_STDBOOL, and AM_STDBOOL_H

[Ralf Corsepius]

On 02/01/2011 04:15 AM, Russ Allbery wrote:

Paul Eggert  writes:


In Gnulib:



* Rename gnulib's AC_HEADER_STDBOOL to gl_HEADER_STDBOOL.
* Remove the AC_DEFINE([HAVE_STDBOOL_H], ...) from gl_HEADER_STDBOOL.
* Rename gnulib's AM_STDBOOL_H to gl_STDBOOL_H.



In Autoconf:



* Mark AC_HEADER_STDBOOL as obsolescent, and suggest to
   Autoconf users that in the future they use gnulib if they want to
   be portable to pre-C99 hosts with respect to.


Please don't make this last change in Autoconf.  AC_HEADER_STDBOOL in
Autoconf works well right now for people who do not use gnulib,

Agreed. I am one of these users.


and I
don't think that it's a good idea to mark obsolescent a working Autoconf
macro to try to "push" people towards using gnulib instead.

Agreed, again.

For real-world projects, gnulib often is not a viable alternative.

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Override default CXXFLAGS

[Ralf Corsepius]

On 01/22/2011 03:50 AM, Sergio Belkin wrote:

I answer myself: RTMF :)

"If using the GNU C compiler, set shell variable GCC to ‘yes’. If
output variable CFLAGS was not already set, set it to -g -O2 for the
GNU C compiler (-O2 on systems where GCC does not accept -g), or -g
for other compilers. If your package does not like this default, then
it is acceptable to insert the line ‘: ${CFLAGS=""}’ after AC_INIT and
before AC_PROG_CC to select an empty default instead. "


That's only half of the story ("-O2 -g is gcc-specific").

CXXFLAGS needs to stay overridable from the configure command-line 
(configure CXXFLAGS="..." and from the envirionment

(CXXFLAGS="..." configure).

Ralf

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Corsepius]

On 12/20/2010 08:02 PM, Bruce Korb wrote:

On 12/20/10 09:11, Nick Bowler wrote:

On 2010-12-20 08:54 -0800, Bruce Korb wrote:

If the default build is 64 bit, why does it make sense that the
default library directory is the 32 bit library?


As far as I know, the only reason for this design is to avoid breaking
32-bit proprietary software with /usr/lib paths hardcoded into their
binaries.


Which argues for keeping /usr/lib as a 32 bit library directory,
but not for making it the default directory.


Pardon, but I can not avoid having to reiterate my mantra:
/usr/lib and /usr/lib64 are just one random case of multilibs, which 
happens to be popular on currently far spread and widely used targets.


However, there are _many_ more targets, which apply completely different 
conventions. In particular, they are very wide spread on embedded 
targets, where they often are being used for optimization purposes.



Perhaps all the "stake holders" need to be put into a virtual meeting
room and not allowed out until some way forward is chosen. ;)

Well,

a) Users should learn that autoconf's default are "just arbitrary 
defaults", which match their use-case or not.


This is nothing new. System integrators need to take care about this in 
any case and for uneducated "random users" there a plenty of other 
possiblities to shoot themselves into their own foot (e.g. by installing 
to /usr/local)


b) The solution would be along the lines of

libdir='${exec_prefix}/lib/'"$(${CC} ${CFLAGS} --print-multi-os-directory)"

However, how to implement this into autoconf is far from being clear to 
me, as well as I would expect the details could easily become ugly.



I do think that autoconf was conceived as the place where
inconsistencies between platforms get resolved.  This is an
inconsistency that could really use a resolution that does not
require people to have to remember platform dependent tool use rules.


I wonder why this issue pops up now? It is around for probably more than 
15 years and has never been a major issue. At least the first system I 
personally tripped over, which was using multilibs was a Sun Sparc 
Solaris system ca. in 1995 (Solaris 2.7/SunOS-5.7 or so). The oldest 
piece of code I could find by brief look into GCC's source code dates 
back to 1997.


Ralf

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Corsepius]

On 12/20/2010 04:41 PM, Eric Blake wrote:

On 12/20/2010 08:36 AM, Ralf Corsepius wrote:

If a distro insists on shipping 64-bit libraries under /usr/lib64, then
it would be in the distro's best interest to also ship a config.site
variable that defaults --libdir to the appropriate /usr/lib64 location.

This isn't of much help on multi-arched architectures (such as
Fedora/RHEL x86_64 systems), because any such default would only match
to one of its supported architectures and be wrong on all others.

I disagree with your argument.  config.site can be a full-powered shell
script,


OK, then it should be technically possible to implement this - Whether 
it's useful is a different matters (IMO it's not).


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Corsepius]

On 12/20/2010 04:05 PM, Eric Blake wrote:

On 12/20/2010 07:59 AM, Bruce Korb wrote:

Hi Andy, Ralf, et al.,

On Mon, Dec 20, 2010 at 6:23 AM, Andy Wingo  wrote:

   How much understanding of the machinery should be expected
   of the hapless project builder?


I'm not sure, but: .


I am sure of this:  It needs to be minimized.  If there are insurmountable
problems in figuring out that the lib directory is /usr/lib64,
then the builder has to supply it. I really doubt it is that hard to
figure out though.


If a distro insists on shipping 64-bit libraries under /usr/lib64, then
it would be in the distro's best interest to also ship a config.site
variable that defaults --libdir to the appropriate /usr/lib64 location.


This isn't of much help on multi-arched architectures (such as 
Fedora/RHEL x86_64 systems), because any such default would only match 
to one of its supported architectures and be wrong on all others.


Ralf

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Corsepius]

On 12/20/2010 04:12 PM, Peter Breitenlohner wrote:

On Mon, 20 Dec 2010, Eric Blake wrote:


If a distro insists on shipping 64-bit libraries under /usr/lib64, then
it would be ...


This is not so much a "distro insisting" but rather the Linux file system
standard for bi-arch systems!

multi-arch'ed systems ;)

bi-arch'ed systems are just a special case of multi-arch'ed systems.

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Corsepius]

On 12/20/2010 03:59 PM, Bruce Korb wrote:

Hi Andy, Ralf, et al.,

(With my Fedora Packaging Committee member hat on) In Fedora
and RHEL, users are supposed to pass
  --libdir=/usr/lib64 to configure
on x86_64 and

It is unclear that you-all can do otherwise, without having OSX-style
mixed word size combined libraries.
Fedora + RHEL (and many other Linux distros) apply multilibs and 
multiarching instead of "fat binaries".



   Autoconf does need to get
involved and work with libtool to get the information passed through.
Well, I am not sure what you are asking. --libdir (installation 
directory) and "path to libraries to link to" (linker's library path) 
actually are independent.


The former is a user-/system-integrator provided setting, which may take 
arbitrary values.


The latter is a system's internal implementation detail - If libtool 
can't avoid exposing these implicit details, it has to examine the tools 
being involved internal settings (In case of Fedora/RHEL: gcc). Correct 
me if I am wrong, but as far as I can tell libtool doesn't do so, so far.
The same consideration applies to applications/application configure 
scripts who want to guess for a "system's" libdir.


Wrt. autoconf: There have repeatedly been discussion on letting autoconf 
provide different defaults for libdir on 64bit targets, but ...
... besides that guessing on system defaults is difficult, do you 
realize that the setting autoconf provides are simply defaults, user 
will almost always have to change?


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: How to best prevent autoreconf from recursing into a subdir

[Ralf Corsepius]

On 12/01/2010 08:45 AM, Peter Breitenlohner wrote:

On Wed, 1 Dec 2010, Ralf Wildenhues wrote:


(1) is there a better (more correct) way to achieve the same result?


Yes; see 'info Autoconf Subdirectories' for better code, and info
autoreconf for the --no-recursive flag.


Hi Ralf,

yes, of course.

Sorry, my explanation missed an important point: we do want autoreconf to
recurse into subdirectories, just not into this particular one.

My advice would be you to

* redesign your configuration such that autoreconf works.
What you are doing doesn't seem sound to me.

or (principle of least resistance)
* not use autoreconf, but to implement a toplevel "bootstrap"/"autogen" 
style script, you could fill with explicit "cd's" and "autoreconf 
--no-recursive"/"autoreconf" where suitable.


Ralf

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: About AC_CHECK_HEADERS and different locations

[Ralf Corsepius]

On 09/28/2010 04:52 PM, Andrew W. Nosenko wrote:

On Tue, Sep 28, 2010 at 06:13, Sergio Belkin  wrote:

Hi,

I am autoconfiscating a project that has a header file with a line:

#include

configure.ac has:

AC_CHECK_HEADERS(postgresql/libpq-fe.h)

The problem is that Ubuntu has such a header file on
/usr/include/postgresq  but fedora has it on  /usr/include. So how can
I make that configure script checks  for differents paths?


Assuming that
   o  Fedora has requested header as /usr/include/libpq-fe.h
   o  Ubuntu has requested header as /usr/include/postgresql/libpq-fe.h
   (otherwise I see no problems at all, just use CPPFLAGS approrach
as already suggested)

Then you can to check both in configure.ac and use result in the source code:

configure.ac:

AC_CHECK_HEADERS([postgresql/libpq-fe.h libpq-fe.h],
  [break],
  [AC_MSG_ERROR([PostgreSQL headers not found or not usable])])

Source code:

#if defined(POSTGRESQL_LIBPQ_FE_H)
#  include
#elif defined(LIBPQ_FE_H)
#  include
#else
#  error impossible because of AC_MSG_ERROR(), but...
#endif

Of cource you can play with [action-not-found] (for example remove
AC_MSG_ERROR() completely and don't abort configure if nither header
found), and simplify "#include" dance to

#if defined(POSTGRESQL_LIBPQ_FE_H)
#  include
#else
#  include
#endif

for allow tuning CPPFLAGS by hands at the make(1) invocation, for
example...  Or anything what you want.


Much easier than this is modifying the source code to
#include 
instead of
#include 
and to rely on the user passing appropriate CPPFLAGS.

Ralf

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Best practices to detect autoconf version in macro.

[Ralf Corsepius]

On 03/30/2010 04:41 PM, Eric Blake wrote:

On 03/30/2010 03:13 AM, Konstantin Andreev wrote:

Hello.

I need to write a macro, which will be expanded by various versions of
autoconf, including 2.13  :(


Simultaneously targeting 2.59 and newer is moderately easy, and still
supported by this list.  Supporting 2.50 and newer is a bit tougher, but
not intractable.

Agreed.


But simultaneously supporting 2.13 and 2.50+ is MUCH
harder, with very few people even attempting it (my gut feel is that it
is technically still doable, although I won't be the one doing it).

Testing is the problem.

Trying to say 2.13 compatible is likely doable for trivial configure 
scripts, but it easily becomes tedious for complex ones and .., close to 
impossible to test.



If m4_version_compare is defined (added in 2.53, documented in 2.62),
then use it.  Otherwise, you know that you are targeting an older autoconf.

Read this thread for another person who attempted this feat for PHP, and
later gave up, because the changes from 2.13 to 2.50 were so dramatic.

I could tell similar stories.

From my experience, it's way easier to "do the plunge once", i.e. to 
once convert all 2.13 anacronisms and bugward-compatibilities (which 
typically means exploits of autoconf-2.13 internal) to autoconf-2.50+.


At some point, very likely will want to take advantage of some 
autoconf-2.50+ features or finds that certain autoconf versions > 2.50 
provides a feature "one has always missed" in older autoconfs.


The lesson at least I've learnt, is not wanting to look back to 2.13.

BTW: Even more dramatic, similar considerations apply to automake.

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Best practices to detect autoconf version in macro.

[Ralf Corsepius]

On 03/30/2010 04:01 PM, Konstantin Andreev wrote:

On 03/30/10 17:48, Ralf Corsepius wrote:

On 03/30/10 17:48, Ralf Corsepius wrote:

On 03/30/2010 11:13 AM, Konstantin Andreev wrote:

Hello.

I need to write a macro, which will be expanded by various versions
of autoconf, including 2.13 :(

Obviously, things, the macro does, must be accomplished differently.

Could you advice, what is the best way to detect in macro, which
autoconf version is currently expanding, and expand macro
conditionally ?

My advice would be to abandon your plan. It's not useful.


I can not choose the autoconf version. The macro is for Mozilla, and
they stuck at autoconf-2.13, sic!

I can feel the pain, nevertheless ...


I can only attempt to make a "forward
compatible" macro.

... I can only reiterate my advice.

... mozilla missed ca. 10 years of development.

Trying to stay bugward-compatible with a piece of software nobody wants 
to look back at, is doomed to fail.


The best approximation of what you can try to make their configuration 
compatible to a very recent version of autoconf and to abandon 
supporting earlier autoconf-versions.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Best practices to detect autoconf version in macro.

[Ralf Corsepius]

On 03/30/2010 11:13 AM, Konstantin Andreev wrote:

Hello.

I need to write a macro, which will be expanded by various versions of
autoconf, including 2.13 :(

Obviously, things, the macro does, must be accomplished differently.

Could you advice, what is the best way to detect in macro, which
autoconf version is currently expanding, and expand macro conditionally ?

My advice would be to abandon your plan. It's not useful.

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Configure script not at the root of src directory

[Ralf Corsepius]

On 03/20/2010 08:12 AM, Tim Post wrote:



With very few exceptions, however, I don't see the use of _not_ dirtying
up the source directories with objects and other output if proper
cleaning targets exist.


Traditionally, there are 2 primary reasons:

1) Multiple builds, e.g. building with different flags, options.

2) Read-only sources, e.g. sources on read-only-filesystems,
or read-only permissions to a source-tree.

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Motivation for renaming configure.in to configure.ac and its effect?

[Ralf Corsepius]

On 03/08/2010 05:55 PM, Peter Breitenlohner wrote:

On Mon, 8 Mar 2010, Steffen Dettmer wrote:


I'm trying to understand the motivation for renaming configure.in
to configure.ac. If I remember correctly it was related to the
fact that ./config.status or whoever else processes .in files.


IMHO, the only real reason to rename configure.in to configure.ac is, that
some future Autoconf version may cease to accept the 'bugward' compatible
old name.

Only partially.

Suffix rules/mime-types are the keywords you are looking for. Whether 
the files are named *.ac or *.in doesn't make much of a difference to 
autoconf, but to other tools, e.g. automake, GUIs, browsers, editors etc.



Everything else is philosophy/ideology.

Well, I presume your C-sources are named *.jpg?


Ralf

PS.: Yes, I strongly think it's time for autoconf to bury configure.in. 
It's an anachronism worth to ditch, ASAP.




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Motivation for renaming configure.in to configure.ac and its effect?

[Ralf Corsepius]

On 03/08/2010 01:52 PM, Steffen Dettmer wrote:

On Mon, Mar 8, 2010 at 12:29 PM, Ralf Corsepius  wrote:

* On 03/08/2010 12:12 PM, Steffen Dettmer wrote:

I'm trying to understand the motivation for renaming configure.in
to configure.ac. If I remember correctly it was related to the
fact that ./config.status or whoever else processes .in files.


The reason is suffix rules:

*.ac's are processed by "autoconf" (written in the "autoconf-language")


ok, let me rephrase my question:
What was the motivation to change the name of the main file to be
processfrom by autoconf to .ac?

There are many other files processed by autoconf, such as macro
include files. I looked to a few examples in
http://www.gnu.org/software/autoconf-archive but all I picked
were called file.m4 not file.ac (which is fine of course!).

Do we have to expect in future to see a renaming here too?


*.in's are arbitrarily formated, arbitrarily formated files.

This should have been ".. arbitrary, arbitarily formated files"



Is the renaming configure.in to configure.ac cosmetic only


No (cf. above)


Sorry, I didn't get it. Above I understood that it is cosmetic
only (by some convention because configure.in isn't arbitrarily
formated but written in the "autoconf-language", it should be
called configure.ac), so the answer here should be `yes',
shouldn't it?


Well, if you consider naming C-sources *.c being cosmetics, or if you 
prefer to call you C-sources *.jpg, then it's cosmetics.


The tools you are going to use (One of these is autoconf, another one is 
make). It's all suffix rules, mime-types etc.


The fact autoconf-source files used to be called "configure.in" was a 
(minor) bug in older versions of autoconf! The fact autoconf still 
accepts it is legacy to outdated conventions ("bugward compatibility" in 
autoconf slang).



Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Motivation for renaming configure.in to configure.ac and its effect?

[Ralf Corsepius]

On 03/08/2010 12:12 PM, Steffen Dettmer wrote:

Hi,

I'm trying to understand the motivation for renaming configure.in
to configure.ac. If I remember correctly it was related to the
fact that ./config.status or whoever else processes .in files.


The reason is suffix rules:

*.ac's are processed by "autoconf" (written in the "autoconf-language")

*.in's are arbitrarily formated, arbitrarily formated files.

> Is the renaming configure.in to configure.ac cosmetic only
No (cf. above)

> and
> is it safe to keep configure.in in old projects/branches?
No, you should rename them. Keeping configure.in's doesn't make no sense 
at all.


Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: AC_CHECK_FUNCS and gcc with -Werror

[Ralf Corsepius]

On 03/03/2010 03:27 PM, Steffen Dettmer wrote:

On Wed, Mar 3, 2010 at 2:44 PM, Eric Blake  wrote:

According to Steffen Dettmer on 3/3/2010 6:33 AM:

Do I understand correctly that it is generally adviced to not use
the option -Werror?


Not quite.  The advice is to not mix -Werror and configure.


ahh ok, this is fine!
There is no need to have -Werror during configure.
So it seems again we just do the things wrongly :)
But how to do it correctly?


Post-configure, you can use -Werror to your heart's content, and I do it
all the time in packages that I maintain.


I'm not sure if I get this...
How do I use -Werror or -WX post-configure correctly?


Several ways:

a) Override CFLAGS at make time:
./configure CFLAGS=""
make CFLAGS="This is what I would do - It doesn't clutter the autotool-files with 
GCC-proprietary -Werror handling and is appropriate for development 
purposes.



b) Implement it as a conditional AC_SUBST, i.e.
something similar to

AC_ARG_ENABLE([werror],
...
/* if gcc */
CFLAGS_WERROR="-Werror"
...
/* if other compiler */
CFLAGS_WERROR=""
...
])
AC_SUBST([CFLAGS_WERROR])


accompanied by something similar to this in your Makefile.in's
CFLAGS = @CFLAGS@ @CFLAGS_WERROR@
rsp. (in case of using automake)
AM_CFLAGS = @CFLAGS_WERROR@

I would not want to use this approach.

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: AC_CHECK_FUNCS and gcc with -Werror

[Ralf Corsepius]

On 03/03/2010 02:44 PM, Eric Blake wrote:

According to Steffen Dettmer on 3/3/2010 6:33 AM:

what to do best here?

Not using -Werror


That's been the standard advice for years now.


Do I understand correctly that it is generally adviced to not use
the option -Werror?


Not quite.  The advice is to not mix -Werror and configure.
Post-configure, you can use -Werror to your heart's content, and I do it
all the time in packages that I maintain.  And it is even possible to let
configure check whether -Werror works, and if so, automatically add it to
CFLAGS.  It's just that configure checks themselves are not guaranteed to
be warning-free, so converting warnings to errors during configure is a
recipe for disaster.  In other words, the advice is that you shouldn't use
'./configure CFLAGS=-Werror'.


Another aspect is -Wall and -Werror are moving (and architecture 
dependent) targets. I.e. the number of warnings GCC will issue changes 
over time, triggering different kind of warnings.


I.e. when using -Werror a configure script will fail for different kinds 
of reasons at different places depending on your toolchain.


I.e. the best your "Development Rules" will be able to achieve is 
"warning free" compilation in a very narrowly pre-defined setup, with a 
well defined toolchain.



Don't do something if it hurts.


mmm... (I think the idea is to make a warning hurting to ensure
that it is fixed instantly and cannot be overseen / forgotten).


The problem is that no one has submitted a patch to make configure and
-Werror try to play nicely, until last month; and even then, it is not the
easiest thing in the world to do.
There is another aspect: There exist configure-checks which rely on 
switching on/off -Werror. I haven't checked how this recent submission 
co-exists with such kind of configure-checks.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: AC_CHECK_FUNCS and gcc with -Werror

[Ralf Corsepius]

On 03/03/2010 11:52 AM, Steffen Dettmer wrote:

Hi,

in configure.in I have:

AC_CHECK_FUNCS(printf)

together with some

--->8===
AC_DEFUN([IC_ENABLE_ERRORS],[
   AC_ARG_ENABLE(errors,
 [ --enable-errors[=ARG] Enable error mode
 (warnings are errors) [ARG=no]],
   
   if test x$enable_errors = xyes ; then
 case $CC in
   dnl Just in case someone would have a non-gcc "thingcc", don't match *gcc
   gcc|*-gcc)
 CFLAGS="$CFLAGS -Werror";
 ;;
===8<---



In config.log then:

configure:11204: gcc -o conftest  -Wall -Wmissing-prototypes
-fstrict-aliasing -D_GNU_SOURCE -ansi -ggdb -D_REENTRANT -Werror
-ggdb conftest
.c  -lpthread>&5
cc1: warnings being treated as errors
conftest.c:67: warning: conflicting types for built-in function 'printf'

what to do best here?

Not using -Werror

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Finding dependencies in lib64 or lib

[Ralf Corsepius]

On 02/17/2010 01:39 PM, Dr. David Kirkby wrote:

Ben Taylor wrote:

On Thu, Feb 11, 2010 at 11:00 AM, Konstantin Andreev
 wrote:



In Solaris, libraries live in

32-bit : /usr/lib
64-bit : /usr/lib/64


where 64 -> amd64 or sparcv9


There's also /lib/amd64 and /lib/sparcv9. /usr/lib and /lib are *not*
linked.

I've noticed that some software installs files in places
/usr/local/amd64 or /usr/local/sparcv9, but does not create the link to
the "64" directory.

It is a bit of a mess.
I can only reiterate what I previously wrote: There are hundreds of such 
multilib subdirs. Their names can be arbitrarily choosen by OS vendors.


Extreme cases can be found in embedded systems, which often provide 
highly-optimized multilibs for many cpu-variant.

=> Any such heuritics is inevitably broken.
It's only that these heuristic's implementors likely haven't tripped 
over these "less common" cases and believe the few they have encountered 
are the only ones:



Just to provide further examples:

* sun-sparc-solaris2.7 (Antique/discontinued, > 10 years old):
lib
lib/sparcv9

* sparc for RTEMS (an embedded OS):
lib
lib/soft
lib/v8
lib/soft/v8

* powerpc for RTEMS (an embedded OS):
lib
lib/m403
lib/m505
lib/m601
lib/m603e
lib/m604
lib/m860
lib/m7400
lib/m8540
lib/nof
lib/m601/nof
lib/m603e/mpc8260
lib/m603e/nof
lib/m603e/mpc8260/nof
lib/m604/nof
lib/m7400/nof
lib/m8540/nof


For comparison: Red Hat x86_64-gcc
lib
lib64

Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Tips to modernize autotools configuration

[Ralf Corsepius]

On 02/17/2010 04:18 AM, Javier Jardón wrote:

Hello,

I've created this page: [1]
with some tips to modernize the autotools configuration of GNOME (or
others) projects.

As I'm not an autotools expert, It would be great if someone of you
take a look to the page to correct the possible mistakes.
(Feel free to edit the page directly or comment here the issues)

Best regards,

[1] http://live.gnome.org/GnomeGoals/ModernAutotools


My personal remarks on your document:

- Don't use ACLOCAL_FLAGS
Modern configuration setups don't need it.

- AM_MAINTAINER_MODE has valid use cases. Though I agree with your 
intention to discourage users from using it, your formulation is way too 
strict, IMO.


- Recommend automake >= 1.11.1.
automake 1.10 is known to be suffering from critical security issues.

- Recommend using vanilla FSF autotools- -not the versions vendors ship, 
because they typically have patches which can render modifying/patching 
auto*tool files difficult.



What I am missing:

- Ship tarballs with all sources and generated files included.

- Don't run autoreconf/autogen.sh during builds.

- Don't exploit autotools's internals.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Finding dependencies in lib64 or lib

[Ralf Corsepius]

On 02/11/2010 03:51 PM, Daniel Pocock wrote:

Peter Breitenlohner wrote:

On Thu, 11 Feb 2010, Daniel Pocock wrote:




I agree that this is one solution, and Ralf's suggestion about LDFLAGS
is also valid of course.

I didn't see any example in the documentation endorsing a particular
approach,
Well, the LDFLAGS, CPPFLAGS, CFLAGS approach is intrinsic to 
autoconf/automake.


It's just a standard use-case of autoconf/automake, which doesn't need 
special casing. It also is the standard use-case, how distribution 
packagers apply autoconf/automake.



and every project I've looked at seems to handle the problem
in a slightly different way.  Of course maybe many of them are a little
broken.
Exactly. There is a lot of confusion about this topic around, and a lot 
of uncooked recipes around, seemingly stemming from people who never 
used multilibs and multiarched systems.



There is another case that we handle as well: some libs provide a
-config script, e.g. apr-1-config, so you can specify
These kind of config scripts are problem-zone of their own, because many 
of them are not multilib-ready.


E.g. many projects *-config scripts which stem off from early 
gtk-config/glib-config ... unfortunately, these were not multilib ready.


The feature pkg-config adds, is it providing a systematic (though 
arguable) approach - But this is yet another topic.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Finding dependencies in lib64 or lib

[Ralf Corsepius]

On 02/11/2010 03:14 PM, Daniel Pocock wrote:

Ralf Corsepius wrote:
   

On 02/11/2010 12:37 PM, Daniel Pocock wrote:
 


Hi,

I've been looking over configure.in for the Ganglia project.

The project depends on some other libs, and their locations can be
specified with configure arguments, for example:

--with-libconfuse=/usr/local

The original configure.in would then try -L/usr/local/lib

However, there are platforms where 64 bit libraries should be in
*/lib64, e.g. the search for libconfuse should try /usr/local/lib64 on
those platforms.

My initial solution is to test $host

LIB_SUFFIX=lib
case $host in
x86_64-redhat-linux*)
LIB_SUFFIX=lib64
esac

but a proper solution
   

A proper solution is not to try tricks like the one above, but to let
the user specify the directory he needs, if he needs special settings.

In most cases he won't have to, because on e.g. on redhat-based systems,
/usr/lib64 is in of GCC's default library search path.
 

It is not quite so simple


It is


- the third party library may be installed
elsewhere, e.g. /opt/confuse-2.6/lib64
   


configure LDFLAGS=-L/opt/confuse-2.6/lib64

The --with-libconfuse option only accepts the base directory (e.g.
--with-libconfuse=/opt/confuse-2.6)

Well, your approach is broken :)

On a wider scale, it is even more broken than you might think:

The fact some systems use "lib64" actually is arbitrary. The, what you 
call "LIB_SUFFIX" is a more or less arbitrary chosen convention of the 
OS vendor.


Many embedded system's compilers e.g. use many multilibs, with many 
different library names.
Even some *nix'sh OSes do so (E.g. some sparc Solaris variants did (do? 
I don't have access to Solaris machines anymore) so).



  and configure has to decide whether
to append /lib or /lib64 to find the right dependencies.

On some systems (e.g. a host used for building 32 and 64 bit packages),
there may be two versions of libconfuse installed, e.g.

/opt/confuse-2.6/lib/libconfuse.so (32 bit)
   

configure LDFLAGS=-L/opt/confuse-2.6/lib \
  CPPFLAGS=-I/opt/confuse-2.6/include \
  CFLAGS="-g -O2 -m32" \
--libdir=/opt/confuse-2.6/lib
...


/opt/confuse-2.6/lib64/libconfuse.so (64 bit)

and our original configure.in would never look in the 64 bit directory.

   

configure LDFLAGS=-L/opt/confuse-2.6/lib64 \
  CPPFLAGS=-I/opt/confuse-2.6/include \
  CFLAGS="-g -O2 -m64" \
--libdir=/opt/confuse-2.6/lib64
...

Ralf



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Finding dependencies in lib64 or lib

[Ralf Corsepius]

On 02/11/2010 12:37 PM, Daniel Pocock wrote:



Hi,

I've been looking over configure.in for the Ganglia project.

The project depends on some other libs, and their locations can be
specified with configure arguments, for example:

--with-libconfuse=/usr/local

The original configure.in would then try -L/usr/local/lib

However, there are platforms where 64 bit libraries should be in
*/lib64, e.g. the search for libconfuse should try /usr/local/lib64 on
those platforms.

My initial solution is to test $host

LIB_SUFFIX=lib
case $host in
x86_64-redhat-linux*)
   LIB_SUFFIX=lib64
esac

but a proper solution


A proper solution is not to try tricks like the one above, but to let 
the user specify the directory he needs, if he needs special settings.


In most cases he won't have to, because on e.g. on redhat-based systems,
/usr/lib64 is in of GCC's default library search path.


needs to test against all the architectures listed
in the FHS:

http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64

and also know about the non-FHS compliant cases (e.g. Debian)

Is anyone aware of macros for doing this and helping me set LIB_SUFFIX
correctly for a particular $host?

Seriously, simply not caring about "LIB_SUFFIX"es is the best solution.



Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Changing prefix for recursive autoconf subprojects

[Ralf Corsepius]

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 contain others subprojects, and A may or may not be itself a
subproject of Z, but I don't think this is relevant).

Problem: I need the recursive 'make install' on project B to install
into the prefix dir passed down by A, but I need the recursive 'make
install' on C to install into a subdirectory of A's prefix. To be
concrete, if $prefix is "/usr/local" I want B to install into
"/usr/local" but I need subproject C to install into "/usr/local/foo".
The reason is to avoid overwriting a potential existing installation of
the subproject C that may have been installed previously since we
modified the source. Unfortunately, we cannot make C a separate project
for dependency reasons.

Is there a way to append a subdirectory to the prefix passed down to one
subproject but not the other with autoconf? Or is there perhaps another
way to do this that does not use autoconf?


There are several ways, unfortunately there is no simple one:

a) As you already outline, getting rid of this sub-project and relying 
on it being supplied externally would be the cleanest approach.



b) Use a customized macro working similar to AC_CONFIG_SUBDIRS macro 
internally works (normally found in /usr/share/autoconf/status.m4), but 
with additional argument parsing/processing added.


Though this approach definitetly initially is tedious and error prone, I 
have been using it in a larger project for several years and found it to 
be surprisingly reliable and long time stable.



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 "configure".
I.e. theoretically one could add a "configure.gnu" script, which would 
act as a wrapper script to "configure", i.e. receive the original 
arguments, would parse/process them and invoke the real 
"configure"-script in the end.


I've never tried this approach, but ... it could be worth a try.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: autoconf vs

[Ralf Corsepius]

On 12/02/2009 04:44 AM, Erik de Castro Lopo wrote:

Eric Blake wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Erik de Castro Lopo on 12/1/2009 8:12 PM:

 AC_LANG([C++])
 AC_ADD_CXXFLAGS([-std=gnu++0x])
 AC_CHECK_HEADER(cstdint)


With proper m4 quoting, that would be:

AC_CHECK_HEADER([cstdint])


 checking cstdint usability... yes
 checking cstdint presence... no
 configure: WARNING: cstdint: accepted by the compiler, rejected by the 
preprocessor!
 configure: WARNING: cstdint: proceeding with the compiler's result
 checking for cstdint... yes


Can we see the corresponding config.log?


Ah, that shed some light:

 configure:18130: checking if g++ accepts -std=gnu++0x
 configure:18147: g++ -o conftest -g -O2 -Wall -Wextra -Wsign-compare 
-Wno-ctor-dtor-privacy
 -Wno-non-virtual-dtor -Wformat -Werror -Wno-deprecated -std=gnu++0x   
conftest.cpp -lcups>&5
 configure:18147: $? = 0
 configure:18148: result: yes
 configure:18160: checking cstdint usability
 configure:18160: g++ -c -g -O2 -Wall -Wextra -Wsign-compare 
-Wno-ctor-dtor-privacy \
 -Wno-non-virtual-dtor -Wformat -Werror -Wno-deprecated -std=gnu++0x  
conftest.cpp>&5
 configure:18160: $? = 0
 configure:18160: result: yes
 configure:18160: checking cstdint presence
 configure:18160: g++ -E  conftest.cpp
 In file included from /usr/include/c++/4.4/cstdint:35,
  from conftest.cpp:32:
 /usr/include/c++/4.4/c++0x_warning.h:31:2: error: #error This file 
requires compiler and
  library support for the upcoming ISO C++ standard, C++0x. This 
support is currently
  experimental, and must be enabled with the -std=c++0x or -std=gnu++0x 
compiler options.
 configure:18160: $? = 1


The problem is that when checking for, -std=gnu++0x is not on the
command line.


Look again. AFAIS from your config.log, -std=gnu++0x is on the command line.

AFAICT, your problem is you using -Werror. By applying it the warning 
gcc issues becomes an error which causes the check in configure to break.


Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: silent-rules

[Ralf Corsepius]

On 10/14/2009 02:58 AM, Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Corsepius on 10/13/2009 9:20 AM:

What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?

Exactly this is the problem.


The problem isn't the support for silent rules.  The problem is that
some packages are enabling it by default


But YOU can still disable it by default, by writing your packaging
automation tools to supply --disable-silent-rules as part of calling
./configure, and/or writing an appropriate config.site.  In other words,
the person running ./configure STILL has the option to choose YOUR desired
default, even if it is different than the package author's desired
default.


Exactly what I said in a previous mail: Automake is pushing around 
package maintainers to modify their packages to automake's behavioral 
changes. (Here package maintainer == Package installers)


> The use of silent-rules is an option, not a mandate.
IMO, upstream maintainers, who use silent rules, don't have much clues 
about what they are doing - Their practice is harmful.




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: silent-rules

[Ralf Corsepius]

On 10/13/2009 04:49 PM, Bob Friesenhahn wrote:

On Tue, 13 Oct 2009, Ralf Corsepius wrote:


The problem is verifying "correctness of building" packages in batches.

i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler 
calls etc. for correctness


(NB: A package, which compiles without warning doesn't mean it is 
being built correctly.)



What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?

Exactly this is the problem.


The problem isn't the support for silent rules.  The problem is that 
some packages are enabling it by default
Indeed. What makes the situation worse is some upstreams shipping 
"common" aclocal-macros which enable it by default. This cause quite 
some amount of surprises when analysing buildlogs of packages which for 
whatever reasons run autoreconf/autogen.sh.



because it looks like Linux and Linux is cool.

:=)

Ralf



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: silent-rules

[Ralf Corsepius]

On 10/06/2009 09:52 PM, Ralf Wildenhues wrote:

[ adding automake@ ]

Hello Ralf,

* Ralf Corsepius wrote on Tue, Oct 06, 2009 at 05:49:52PM CEST:

a) AM_SILENT_RULES are harmful (I know, you know that I think about
this (mal-) "feature" this way - Working around the issues they are
causing in Fedora packaging is a major nuissance.)


Could you expand on this nuisance a bit more?

I did so several times before.

Anyway, ...

The problem is verifying "correctness of building" packages in batches.

i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler calls 
etc. for correctness


(NB: A package, which compiles without warning doesn't mean it is being 
built correctly.)



What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?

Exactly this is the problem.

It means automake is pushing around package maintainers to modify their 
packages to automake's behavioral changes.


As many package maintainers are no autotools' specialists, this is a 
non-trivial problem.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: checking automake version in configure.ac

[Ralf Corsepius]

On 10/06/2009 04:52 PM, Eric Blake wrote:

Ralf Corsepius  freenet.de>  writes:


... I don't want that behavior. I just want to add a feature, not to
forbid a user to rebuild the files.

The desired behavior TOTALLY makes sense (although this is an automake
question, not an autoconf question)

  >  - an example is the use of color-tests

when available, with a clean fallback to no color-tests if an older
automake was sufficient for everything else.


Well, this is an entirely different use-case.

This is changing the configure's behavior at configure run-time. It is
not the running "autogen.sh" (autoreconf) case.


Huh?


Citing from the 1st and 2nd answer to this thread:

Somebody >> If my guessing is right, the popular method would
Somebody >> be packing autogen.sh with version checking.
Vincent > we actually pack autogen.sh. Checking the version of
Vincent > automake in it and use it in configure.ac is indeed
Vincent > a solution.
Vincent > Is there a better one ?


And whether version checking is an appropriate means/good approach in
general at all, is a different question.


m4_ifdef([AM_SILENT_RULES]) is as good as it gets - it's a feature test, which
is better than a version check.  As long as new automake features are always
given a corresponding feature check ability, then it is possible to write
configure.ac that takes advantage of the features when present without choking
when used with older automake versions.

IMNSHO,
a) AM_SILENT_RULES are harmful (I know, you know that I think about this 
(mal-) "feature" this way - Working around the issues they are causing 
in Fedora packaging is a major nuissance.)


b) having them as optional feature at configure-run-time introduces 
non-deterministic behavior.


Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] checking automake version in configure.ac

[Ralf Corsepius]

On 10/06/2009 01:58 PM, Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Corsepius on 10/6/2009 1:45 AM:

AM_INIT_AUTOMAKE([1.11])


yes, but...


This way, running an insufficient automake on your source files will
error out.


... I don't want that behavior. I just want to add a feature, not to
forbid a user to rebuild the files.

Your consideration doesn't make sense.

If your package requires a minimum version of automake, then your
package can't be rebuilt without a sufficient version of automake,
therefore the user must be stopped running his automake.


The desired behavior TOTALLY makes sense (although this is an automake
question, not an autoconf question)

> - an example is the use of color-tests

when available, with a clean fallback to no color-tests if an older
automake was sufficient for everything else.


Well, this is an entirely different use-case.

This is changing the configure's behavior at configure run-time. It is 
not the running "autogen.sh" (autoreconf) case.


And whether version checking is an appropriate means/good approach in 
general at all, is a different question.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] checking automake version in configure.ac

[Ralf Corsepius]

On 10/06/2009 09:43 AM, Vincent Torri wrote:



On Tue, 6 Oct 2009, Ralf Corsepius wrote:


On 10/06/2009 08:49 AM, Vincent Torri wrote:


Is there a better one ?
Add the minimum version of automake required to _rebuild_ the 
automake generated to the option passed to AM_INIT_AUTOMAKE.


AM_INIT_AUTOMAKE([1.11])


yes, but...

This way, running an insufficient automake on your source files will 
error out.


... I don't want that behavior. I just want to add a feature, not to 
forbid a user to rebuild the files.

Your consideration doesn't make sense.

If your package requires a minimum version of automake, then your 
package can't be rebuilt without a sufficient version of automake, 
therefore the user must be stopped running his automake.


Ralf





___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] checking automake version in configure.ac

[Ralf Corsepius]

On 10/06/2009 08:49 AM, Vincent Torri wrote:


Is there a better one ?
Add the minimum version of automake required to _rebuild_ the automake 
generated to the option passed to AM_INIT_AUTOMAKE.


AM_INIT_AUTOMAKE([1.11])

This way, running an insufficient automake on your source files will 
error out.


Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: project in multiply directories

[Ralf Corsepius]

On 09/28/2009 05:55 PM, Bob Friesenhahn wrote:

On Mon, 28 Sep 2009, Alfred M. Szmidt wrote:


There is an article called "recursive make considered harmful".

IMO, one of the most overrated articles of all times.


According to it, you should have just one Makefile.am in top level
with all the rules (all libs etc). By this, make can show its
strengths best. Often, a Makefile.am "per directory" seems to be
used, but for a new project today this should be avoided. It just
slows things down and leads to unneeded compiler calls.

I'm sorry, but where on earth did you get this terrible information?

A Makefile.am per directory is precisly what should be used, it
doesn't incure any extra compiler calls. It also makes it easy to
build seperate parts of the tree.


The main advantage of a Makefile per directory is that it makes it
easier to request building seperate parts of the tree.

Right. Exactly this is a huge win in bigger projects.


Otherwise the
approach can waste quite a lot of build performance since each sub-make
must stat(2) all off the files required by the Makefile target as well
as all of the generated source file dependencies, and there is quite a
lot of redundant processing (e.g re-linking) which does not need to
occur. A non-recursive build can help avoid depending on archive
libraries and "convenience" libraries which often consume quite a bit of
the build time.

Agreed, ... but the keyword is "can".


I have taken a number of large Automake-based projects (C and C++) to
non-recursive builds and have not regretted it.
I did the same and occasionally regret it. It's as in most situations: 
Everything comes at a price and all approaches have their use-cases.


Ralf



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: including autoconf paths in source

[Ralf Corsepius]

On Fri, 2008-12-12 at 10:09 -0700, John Calcote wrote:
> Ralf,
> 
> The trouble with your approach is that it doesn't solve the original
> poster's issue. The issue was that when such variables are expanded into
> config.h using the regular AC_DEFINE mechanism, environment variables
> don't get expanded in the variable substitution:
Correct, this is why this approach is not advisable. 

I had outlined an alternative.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: including autoconf paths in source

[Ralf Corsepius]

On Fri, 2008-12-12 at 07:52 -0500, Thomas Dickey wrote:
> On Fri, 12 Dec 2008, Ralf Corsepius wrote:
> 
> >> compiler, or test-application).  Putting them in the generated config.h
> >> doesn't run into that problem.
> > Only if done properly.
> 
> I agree (of course: putting them into the generated config.h is assumed
> to be "done properly").
This approach typically trips directory expansion problems. It's bad
advise to new-comers

>   For the rest - your example doesn't address the
> specific case I had in mind,
Which? Or course, the details vary in specific cases, nevertheless this
trick is pretty mighty.

>  so it's perhaps useful advice for another
> topic.
automake's toplevel configury applies this trick - It's borrowed from
there ;)

Ralf
 



___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: including autoconf paths in source

[Ralf Corsepius]

On Fri, 2008-12-12 at 06:22 -0500, Thomas Dickey wrote:
> On Thu, 11 Dec 2008, Jan Engelhardt wrote:
> 
> >
> > On Thursday 2008-12-11 21:38, Monty Taylor wrote:
> >
> >> Hey all,
> >>
> >> I'm wondering if there is a best practice for getting paths such as
> >> locaeldir or datadir into source code. As it stands now in the Makefile
> >> I've got:
> >>
> >> prefix= /usr/local
> >> datarootdir= ${prefix}/share
> >> localedir = ${datarootdir}/locale
> >>
> >> To get localedir into a source file, I've got a section in Makefile.am 
> >> like:
> >>
> >> DEFS = -DLOCALEDIR="\"$(localedir)\"" @DEFS@
> >
> > This is the preferred solution indeed. Not that I see a need for @DEFS@
> > though:
> 
> One of the problems with the "preferred solution" is that it's not trivial
> to pass the flags through a script

One way: Generating such files at "make-time" (not at configure-time):

foo.sh: foo.sh.in Makefile
sed -e "s,[...@]localedir[@],$(localedir)," \
< $(srcdir)/foo.in > foo.sh
chmod +x foo.sh.in

>  (for example, a wrapper for a 
> compiler, or test-application).  Putting them in the generated config.h
> doesn't run into that problem.
Only if done properly.

You need to make sure these are expanded correctly and are invariant to
"make-time" environment variable changes.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: default $(libdir) and bi-arch systems

[Ralf Corsepius]

On Tue, 2008-09-09 at 20:07 -0700, Russ Allbery wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> 
> > This is non-applicable, because there is no general rule to distinguish
> > "64bit compiler flags from 32bit compiler flags", nor any hard-coded
> > rule to which multisubdir a compiler might be using.
> >
> > I.e. an approach trying to snoop for -m32/-m64 would be naive. 
> >
> > If somebody you really wants to set up a "reasonable guess" at a "the
> > multi-subdir in effect", he would have to dig much deeper into a
> > compiler's internals.
> 
> I happened to be looking at this just today and ended up adopting the
> following solution when adding library search paths for third-party
> libraries.

Well, this is limited to distinguishing 32/64, i.e. is only applicable
to a very small (though far spread) subset of OSes.

But even on them this seems to lacks quite some amount of generality,
such as case of using real multi-arching, e.g. as building 32bit-ABI
binaries on 64bit-platforms using a multi-lib'ed/multi-arch'ed gcc.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: default $(libdir) and bi-arch systems

[Ralf Corsepius]

On Tue, 2008-09-09 at 19:57 -0600, Eric Blake wrote:

> >> How about changing the libdir default (currently $exec_prefix/lib) to be
> >> $exec_prefix/lib64 or $exec_prefix/lib/64, respectively, when
> >>   - not cross-compiling, and
> >>   - $CC $CPPFLAGS generates 64-bit mode object files, and
> >>   - 64-bit mode object files are installed in /usr/lib64 or /usr/lib/64,
> >> not in /usr/lib ?

> > 2. Linux systems using lib rsp. lib64 are "just special cases" of a much
> > wider set of scenarios. At least some aspects of you wanting to exclude
> > cross-compilation probably originates from this, because "multi-libing"
> > is pretty common on embedded systems.
> 
> Yes, I agree that there are more than just Linux and Solaris scenarios
> that would be worth supporting, if it is easy to maintain.

The fundamental oversight in this proposal is the desire to wanting to
distinguish 64bit and 32bit systems. multilibing actually is about
supporting several ABIs in parallel. 

64/32 bit ABIs on Linux actually are a very special case.

>   The BEST place
> to fix this is in various config.site files
Well, IMO, config.site is not an appropriate place for these kind of
scenarios, because it isn't able to handle multilibs at all.

This deficiency has been the reason for me to discourage people from
applying config.site and for wishing upstream autoconf to let it die.

>  (the logic for determining
> whether a build is using a 64-bit compiler, and thus whether it should
> install into lib64, is best relegated to the platform-specific file).
This is non-applicable, because there is no general rule to distinguish
"64bit compiler flags from 32bit compiler flags", nor any hard-coded
rule to which multisubdir a compiler might be using.

I.e. an approach trying to snoop for -m32/-m64 would be naive. 

If somebody you really wants to set up a "reasonable guess" at a "the
multi-subdir in effect", he would have to dig much deeper into a
compiler's internals.

> Even a patch to the manual to mention how such a config.site should look
> would go a long way.  But too many system integrators are not aware of the
> need to install sane config.site files.  I guess this proposal boils down
> to whether it makes sense to have Autoconf help out in this case by
> changing the defaults without needing config.site to do so.
> 
> > 
> > 3. libdir/choosing compiler flags is not related to multi-arching
> > (having several instances of runtime-libs installed in parallel), it is
> > "multi-libing" (installing several instances of devel/link-libs in
> > parallel).
> > 
> > 4. CPPFLAGS is not necessarily the appropriate place to set up compiler
> > flags for multilibs. In general, you will want either to set CFLAGS or
> > even override CC.
> 
> Again, counterpoints 3 and 4 are irrelevant to the proposal
OK, I miss-read this part of his posting.

>  - Bruno was
> not asking that autoconf change compiler flags based on architecture, but
> that it change installation locations based on snooping existing compiler
> flags.
This would be very difficult. Remember the lib64/lib issue libtool has
been suffering from for many years (AFAICT it still is) and has caused
Linux distribution vendors to apply hacks to libtool covering their
particular demands.

>   I'm interested in seeing a patch along the lines Bruno is
> suggesting, and think it has a chance of being favorably reviewed,
> although it won't make it into the 2.63 release.  But I don't have much
> experience with multilib platforms myself,

I maintain ca. 10+ embedded GNU-toolchains and several 
Linux-> cross GNU-toolchains ;)

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: default $(libdir) and bi-arch systems

[Ralf Corsepius]

On Wed, 2008-09-10 at 01:00 +0200, Bruno Haible wrote:
> Hi,


> But when people configure GNU packages built with autoconf in 64-bit mode,
> "make install" will by default install the libraries in $prefix/lib. This
> leads to two problems:
>   1) If the user has already installed 32-bit libraries with the same
>  --prefix setting, 32-bit and 64-bit mode libraries overwrite each other
>  in $prefix/lib, leading to installed programs that don't run any more,
>  configurations that don't find previously installed libraries, etc.
>   2) If the user is using a fresh --prefix setting but not thinking about
>  $libdir, the installed libraries will not be found by tools which look
>  in the appropriate directory (such as the gnulib 'havelib' module, or
>  the Solaris linker).
> 
> How about changing the libdir default (currently $exec_prefix/lib) to be
> $exec_prefix/lib64 or $exec_prefix/lib/64, respectively, when
>   - not cross-compiling, and
>   - $CC $CPPFLAGS generates 64-bit mode object files, and
>   - 64-bit mode object files are installed in /usr/lib64 or /usr/lib/64,
> not in /usr/lib ?
-1

This would be way too simple (read: incorrect and broken), for many
reasons:

1. This proposal mixes configuration and packaging/system-integration
(CPPFLAGS, changing libdir). Better leave packaging (such as  choosing
CPPFLAGS, libdir) to system-integrators. Whatever you choose, will
always be wrong (and potentially collide) somewhere.

2. Linux systems using lib rsp. lib64 are "just special cases" of a much
wider set of scenarios. At least some aspects of you wanting to exclude
cross-compilation probably originates from this, because "multi-libing"
is pretty common on embedded systems.

3. libdir/choosing compiler flags is not related to multi-arching
(having several instances of runtime-libs installed in parallel), it is
"multi-libing" (installing several instances of devel/link-libs in
parallel).

4. CPPFLAGS is not necessarily the appropriate place to set up compiler
flags for multilibs. In general, you will want either to set CFLAGS or
even override CC.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Noooooooooo!

[Ralf Corsepius]

On Tue, 2008-09-02 at 13:22 -0500, Bob Friesenhahn wrote:
> On Tue, 2 Sep 2008, Harlan Stenn wrote:
> 
> > I've used cross-compiles (off and on) for years and I gotta say the
> > first time I got this message I probably did some pissing and moaning.
> > But I do believe that proper naming is the way to go.
> >
> > Then I created the proper names using symlinks and the problem went
> > away.
> >
> > I've yet to see a case where fixing this in the way autoconf "wants" is
> > even mildly difficult.
> 
> Same here.  The course has been set.  Let's stick with it.

Seconded.

I applaud to the fact pkg-config seems to have joined in the family of
cross-tools. This tremendously eases "real cross-compilation".

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: CFLAGS for AC_COMPILE_IFELSE.

[Ralf Corsepius]

On Tue, 2008-05-13 at 13:11 -0500, Bob Friesenhahn wrote:
> On Tue, 13 May 2008, Ralf Corsepius wrote:
> >
> > /usr/include (and /usr/lib) + /usr/local/include (and /usr/local/lib)
> > are special to GCC, they are on the system-default (include, library)
> > search paths, and are treated differently than other directories by GCC
> 
> More often than not, the formally installed GCC ignores 
> /usr/local/include.  For example, the GCC that comes with OS-X Leopard 
> does not look there.  The GCC that comes with FreeBSD 7.0 does not 
> look there.  On the other hand, the 'cc' that came with SunOS 4.1.3 
> does check /usr/local/include by default, so the GCC install for that 
> target did check /usr/local/include by default so that it would match 
> the system compiler.  It should not be assumed that if the compiler is 
> GCC that it will pay any attention to /usr/local/include.
Vendor supplied "cc"s (traditionally closed source), traditionally don't
look into /usr/local/include.

FSF-GCC's do, because they treat /usr/local/{lib/include} as the
directories to put files into which are supposed to replace vendor
supplied files.

That said, the behavior you describe for OS-X's cc doesn't surprise me,
but I can't find FreeBSD's  behavior helpful.

Ralf





___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: CFLAGS for AC_COMPILE_IFELSE.

[Ralf Corsepius]

On Tue, 2008-05-13 at 18:01 +0200, Edward Tomasz Napierala wrote:
> On 0512T0631, Ralf Corsepius wrote:
> > > I need the configure script to figure out how many parameters one 
> > > particular
> > > library function requires, due to API change.  I've found a macro to do 
> > > that,
> > > it looks like this:
> > > 
> > > AC_DEFUN([AC_JACK_MIDI_NFRAMES_CHECK], [
> > > AC_MSG_CHECKING([whether JACK MIDI functions need nframes parameter])
> > > AC_LANG_PUSH(C)
> > > AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[
> > > #include 
> > > #include 
> > > ]], [[
> > > jack_midi_event_get(0, 0, 0, 0);
> > > ]]), [jackmidi_nframes='yes'], [jackmidi_nframes='no'])
> > > AC_MSG_RESULT([$jackmidi_nframes])
> > > AC_LANG_POP()
> > > ])
> > > 
> > > Problem is, it does not work for me.  Probable reason is this
> > > (from config.log):
> > > 
> > > configure:5138: checking whether JACK MIDI functions need nframes 
> > > parameter
> > > configure:5172: gcc -c -g -O2  conftest.c >&5
> > > conftest.c:32:23: error: jack/jack.h: No such file or directory
> > > conftest.c:33:27: error: jack/midiport.h: No such file or directory
> > > 
> > > It does not work, because it does not use the proper CFLAGS - this
> > > is FreeBSD, includes live in /usr/local/include and it's neccessary
> > > to pass -I/usr/local/include.
> > Are you saying, they modified their GCC in such a way that it doesn't
> > look into /usr/local/include?
> 
> Yes, it seems so.
Really? This would seem rather stupid to me ... ;)

> > GCC's default behavior is to
> > use /usr/local/include implicitly, as part of GCC's system-include path,
> > in a similar way it treats /usr/include.
> 
> What about systems that put external libraries somewhere under
> /opt or /usr/pkg?

/usr/include (and /usr/lib) + /usr/local/include (and /usr/local/lib)
are special to GCC, they are on the system-default (include, library)
search paths, and are treated differently than other directories by GCC 

Any other directory, by default is not on GCC's default search paths and
must be manually added to calls to GCC.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: CFLAGS for AC_COMPILE_IFELSE.

[Ralf Corsepius]

On Sun, 2008-05-11 at 11:57 +0200, Edward Tomasz Napierala wrote:
> I need the configure script to figure out how many parameters one particular
> library function requires, due to API change.  I've found a macro to do that,
> it looks like this:
> 
> AC_DEFUN([AC_JACK_MIDI_NFRAMES_CHECK], [
> AC_MSG_CHECKING([whether JACK MIDI functions need nframes parameter])
> AC_LANG_PUSH(C)
> AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[
> #include 
> #include 
> ]], [[
> jack_midi_event_get(0, 0, 0, 0);
> ]]), [jackmidi_nframes='yes'], [jackmidi_nframes='no'])
> AC_MSG_RESULT([$jackmidi_nframes])
> AC_LANG_POP()
> ])
> 
> Problem is, it does not work for me.  Probable reason is this
> (from config.log):
> 
> configure:5138: checking whether JACK MIDI functions need nframes parameter
> configure:5172: gcc -c -g -O2  conftest.c >&5
> conftest.c:32:23: error: jack/jack.h: No such file or directory
> conftest.c:33:27: error: jack/midiport.h: No such file or directory
> 
> It does not work, because it does not use the proper CFLAGS - this
> is FreeBSD, includes live in /usr/local/include and it's neccessary
> to pass -I/usr/local/include.
Are you saying, they modified their GCC in such a way that it doesn't
look into /usr/local/include? GCC's default behavior is to
use /usr/local/include implicitly, as part of GCC's system-include path,
in a similar way it treats /usr/include.

> So, the question is, how to modify the above macro to use CFLAGS it got
> (or should got) from pkg-config, for example?
You should not do this. Instead, the user/installer is supposed to pass
appropriate *FLAGS to configure.

In your case (include-paths): /configure CPPFLAGS="-I/include"

Ralf





___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: dpkg hooks

[Ralf Corsepius]

On Sun, 2007-09-30 at 09:06 +0100, William Pursell wrote:
> Eric Blake wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > According to William Pursell on 9/29/2007 11:14 AM:
> >> I'm talking about those files named $cache_file in
> >> my $CONFIG_SITE.  Since they hold lines of the form:
> >> ac_cv_func_foo=${ac_cv_func_foo=yes}
> >> the cache is invalid if I remove the package
> >> containing libfoo.
> > 
> > One of the easiest ways to do this is use a site configuration to enforce
> > a global cache file.  Then, when removing a package, you merely delete the
> > global cache (since the state it cached is out of date), and any package
> > you then recompile will have to rerun tests for uncached data, but can
> > share information learned from other packages and saved in the global cache.
> > http://www.gnu.org/software/autoconf/manual/html_node/Site-Defaults.html#Site-Defaults
> > 
> 
> 
> I'm not convinced of the practicality of a single global cache file.
Agreed. IMO config.site is not useful.

> In fact, I found it completely impractical, as invoking configure
> with different settings of CFLAGS would report that the cache
> was invalid and needed to be purged.
What's even worse: A carelessly set up config.site interferes with
cross-compilation.

> I think my underlying question boild down to:
> is there anyway to update a cache file,
None that I am aware about.

>  or is the
> accepted technique to simply remove it and start over?
My recommendation: Don't use config-caches.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: conversion to git

[Ralf Corsepius]

On Thu, 2007-09-20 at 17:16 -0700, Russ Allbery wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-09-20 at 00:04 -0700, Russ Allbery wrote:

> > True, but do you feel subversion is progress?
> 
> Absolutely.  Significant progress. 
Well my experiences with SVN are different. Esp. GCC having switched to
SVN is close to having had disasterous impact on my work.

>  It's been a major improvement in
> efficiency, usability,
These points are those which I do not agree upon from a user
perspective. 

Branching, diffing, grep'ing, etc. inside of check-outs and check-out
sizes is where if find SVN has regressed in comparison to CVS.

The only features SVN provides I found useful, which are missing in CVS,
is it allowing moving/renaming files.

Anyway, this is off-topic for this list, so let's stop here. We'll see
if this sudden move to git, proves sustainability (I don't have any
experiences with git - But having not been able to avoid hg/mercurial in
recent past, I came to the conclusion that hg's usability is not in a
shape to be wanting it for public use.)

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: conversion to git

[Ralf Corsepius]

On Thu, 2007-09-20 at 00:04 -0700, Russ Allbery wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> > On Wed, 2007-09-19 at 21:01 -0700, Russ Allbery wrote:
> 
> >> I think in practice adoption drives portability more than the other way
> >> around.  I don't think CVS became popular because it was portable;
> 
> > Well, I think it became popular, because it had been and still IS lean,
> > simple to use/administrate and matches the demands of most projects.
> 
> I'm fairly certain that's not the case.  The primary advantage of CVS that
> got people to switch to it was that it did considerably more than RCS and
> had considerably more available administrative features and supported
> multiuser development (in other words, was much fatter and was much more
> complex to use, but did more).
Well, I disagree, but you've just pretty nicely described why I find
subversion a temporary and already outdated wart in SCM history ;)

> As soon as something came along that was reasonably polished, did even
> more, and was still free software, CVS started declining fast.  A lot of
> projects had a love/hate relationship with CVS long before there even was
> a replacement, and some free software projects (Perl, for instance) even
> went with proprietary systems because CVS was so limited.  It's almost
> impossible to find new projects these days that start with CVS instead of
> at least Subversion.
True, but do you feel subversion is progress?

As a user, I have to disagree. subversion has not been progress. It's
different, and has different pros and cons, but that's essentially all. 

It's what I feel is the reason why I think people still are striving for
a better SCM.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: conversion to git

[Ralf Corsepius]

On Wed, 2007-09-19 at 21:01 -0700, Russ Allbery wrote:

> I think in practice adoption drives portability more than the other way
> around.  I don't think CVS became popular because it was portable;
Well, I think it became popular, because it had been and still IS lean,
simple to use/administrate and matches the demands of most projects.

This doesn't necessarily apply to many other so-called "more advanced"
SCMs. Some have portability issues, some are arkward to
install/administrate, some have usability issues, some are immature,
etc. ..., and what most of these deny,  many projects don't actually
need the "advanced features" these SCM's promise to provide.

> You're right that all these new systems are exotic or complicated compared
> to CVS.
Right, but ... we will see if autoconf won't regret this move to git.

IMO, this step at this point in time was premature.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

RE: Multi-Line Definitions

[Ralf Corsepius]

On Tue, 2007-09-18 at 15:17 -0600, Eric Lemings wrote:
> 
> > -Original Message-
> > From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] 
> > Sent: Tuesday, September 18, 2007 1:32 PM
> > To: Eric Lemings; [EMAIL PROTECTED]
> > Cc: autoconf@gnu.org
> > Subject: Re: Multi-Line Definitions
> > 
> > Hello Eric,
> > 
> > * Eric Lemings wrote on Mon, Sep 17, 2007 at 11:53:23PM CEST:
> > > 
> > > I have a Autoconf M4 macro that defines a multi-line preprocessor
> > > symbol.
> > [...]
> > > How hard would it be to handle such macro definitions?  Is it even
> > > possible?
> > 
> > Multi-line AC_DEFINEs are not supported currently.  Recently (in
> > Autoconf 2.60), support for multi-line AC_SUBSTs has been implemented.

> > Here it is useful to consider that users may generate output 
> > files that
> > will not be input to a C preprocessor, but some other, 
> > similar language.
> 
> True.  In that case, perhaps the behavior should be language-dependent?
No, AC_DEFINE => c/c++ preprocessor, only.

If you're using them elsewhere, something is broken with your use-case.

Ralf





___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Multi options library

[Ralf Corsepius]

On Sun, 2007-09-02 at 11:53 +0200, Roman Rumisek wrote:
> Exists easy way to build multi option libraries (for example: with/without
> debug feature) into different library names (for example:
> liba_d.so and liba.so)?

The easiest way is to build a package multiple times (once per variant),
with different paths and CFLAGS.

e.g.

configure --libdir=/usr/lib/debug CFLAGS=-g
...
configure --libdir=/usr/lib CFLAGS=
...

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: RFE: Generating a stub Makefile

[Ralf Corsepius]

On Mon, 2007-06-25 at 23:06 -0400, Mark Heily wrote:
> Currently, Autoconf does not generate a top-level Makefile when  

> Here's a simple example of a stub Makefile:
> ---
> all:
>   ./configure
>   make
> 
> install:
>   ./configure
>   make install
> ---
> 
> This idea could be extended to include other targets such as dist,  
> clean, etc.
> 
> My intention is to save typing for power users and make it easier for  
> novice users to build programs from source.
Power users should know how to configure and install a package.

Power users also know that this kind of invocation to build and install
a package almost always is wrong.

>  This effectively hides  
> the Autoconf/Automake mechanism unless someone wants to pass specific  
> options to the configure script.
> 
> Any thoughts?
Not useful.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: NO! autoconf cross-tools detection is really useful!

[Ralf Corsepius]

On Wed, 2007-04-18 at 12:02 -0400, Balint Joo wrote:
> Hi,
> This is a slightly different issue, but here is a feature to please 
> keep,
> or give a new way of doing if it will be changed.
> 
> I often have situations where I have to give some dummy host triplet
> and then explicitly specify the compiler eg for Cray XT3 builds:
> 
> CC="qk-gcc" CXX="qk-g++" --host=x86_64-none-none --build=x86_64-suse-linux
> 
> Here I want cross compilation and the compilers have nothing to do with the
> host triplet etc.
Why? Where do these gcc/g++'s come from.

The GNU toolchain by defaults installs cross tools with the host prefix,
so the person having built these "qk-"prefixed toolchains must have done
something nasty or hasn't understood how prefixing the tools works.

Anyway, if you want to make your like simpler you an simply install
symlinks using the correct prefix.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers

[Ralf Corsepius]

On Thu, 2007-04-12 at 11:04 -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> According to Ralf Corsepius on 4/12/2007 10:43 AM:
> > On Thu, 2007-04-12 at 05:12 -0600, Eric Blake wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> According to Ralf Corsepius on 4/12/2007 4:46 AM:
> >>> To me this reads as: MinGW and Cygwin's "test -x" are broken.
> >> Give an example where cygwin's "test -x" is broken.
> > RTEMS users have reported it for both MinGW and for Cygwin.
> > 
> > Cf. these are the Cygwin variant:
> > http://rtems.rtems.org/pipermail/rtems-users/2007-March/017888.html
> 
> OK, thanks for the pointer - that mail is an example of a cross compiler,
> run on cygwin, but generating non-cygwin files and on a file system that
> lacks executable permission bits.
Why should permission bits matter?

What matters is the executable bit. AFAICT, even old FAT had them.

>   It provides more proof that
> cross-compilers need not do the -x check,
Could you please elaborate why autoconf would a need any -x check at
all?

>  so the recent checkin that only
> turns off -x checking for cross-compilers was correct.
IMO, it is playing with symptoms. Either this -x is always relevant or
it is never relevant.

>   I was more worried
> that you might have come up with an instance where a cygwin native
> executable test was failing.
IMO, the reports proves Cygwin's and MinGW's "test -x" to be defective.

As a consequence of this, this render using "test -x" on both Cygwin and
MinGW a random accident and (in our case) qualify Cygwin and MinGW as
non-suitable hosts for cross-compilation.

Ralf





___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/autoconf

Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers

[Ralf Corsepius]

On Thu, 2007-04-12 at 05:12 -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> According to Ralf Corsepius on 4/12/2007 4:46 AM:
> > To me this reads as: MinGW and Cygwin's "test -x" are broken.
> 
> Give an example where cygwin's "test -x" is broken.
RTEMS users have reported it for both MinGW and for Cygwin.

Cf. these are the Cygwin variant:
http://rtems.rtems.org/pipermail/rtems-users/2007-March/017888.html
http://rtems.rtems.org/pipermail/rtems-users/2007-March/017898.html

And this is the MinGW variant
http://www.rtems.org/bugzilla/show_bug.cgi?id=1228

For Cygwin, the OP reported, switching to NTFS instead of FAT32 would
have remedied his problem.

>   MinGW has problems,
> but in my experience, cygwin does not.

AFAICT from the user reports, the problem is 
"test -x "
failing.

I can supply you with such foreign executables on PM, if you want me to.

Ralf




___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/autoconf

Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers

[Ralf Corsepius]

On Thu, 2007-04-12 at 10:46 +0100, Keith MARSHALL wrote:
> Ralf Corsepius wrote:
> > On Wed, 2007-04-11 at 10:32 -0700, Paul Eggert wrote:
> >> Stepan Kasal <[EMAIL PROTECTED]> writes:
> >>
> >>>  * lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip 
> AS_TEST_X
> >>>  when cross-compiling.
> >>
> >> Thanks, I installed that.
> >
> > Hmm, I am not convinced. If this check can be skipped for cross
> > compilation (Which I think is not correct), why can't it always be
> > skipped?
> 
> As I read the background discussion, leading to introduction of this
> extended test, it appears that it was introduced to appease one broken
> compiler suite,
Wrong. 

It was triggered by running standard autoconf-2.61 configure scripts on
MinGW and Cygwin.

>  running on an elderly minority platform. 
... if you want to label MinGW with this attribute, I agree.

>  In so doing,
> it has broken a feature of autoconf itself, on a current and widely
> deployed platform, namely Microsoft Windows.
Wrong again.

It is triggered by MinGW/Cygwin's "test -x" behavior diverging from
POSIX:

-x  pathname
True if pathname resolves to a file that exists and for which
permission to execute the file (or search it, if it is a
directory) will be granted, as defined in File Read, Write, and
Creation. False if pathname cannot be resolved, or if pathname
resolves to a file for which permission to execute (or search)
the file will not be granted.

NOTE: This definition is completely independent from a file being a
executable natively on a platform.

To me this reads as: MinGW and Cygwin's "test -x" are broken.

Wrt. autoconf this would mean: "test -x" is non-portable. autoconf must
not use it anywhere.

The way easier approach however would be MinGW and Cygwin to be fixed.


Ralf




___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/autoconf

Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers

[Ralf Corsepius]

On Wed, 2007-04-11 at 10:32 -0700, Paul Eggert wrote:
> Stepan Kasal <[EMAIL PROTECTED]> writes:
> 
> > * lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip AS_TEST_X
> > when cross-compiling.
> 
> Thanks, I installed that.
Hmm, I am not convinced. If this check can be skipped for cross
compilation (Which I think is not correct), why can't it always be
skipped?

Ralf




___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/autoconf

Re: VPATH build...

[Ralf Corsepius]

On Tue, 2007-04-03 at 18:02 -0400, Bob Rossi wrote:
> On Tue, Apr 03, 2007 at 04:00:20PM -0600, Ben Bergen wrote:
> > does anyone know of a variable that is defined during the ./configure
> > run that tells where the top level source directory is.  I have tried
> > $top_srcdir, but this is doesn't seem to be defined until the very
> > end.  I can't use the current directory because I am trying to support
> > out-of-path builds.
> 
> Hi Ben,
> 
> I've run into the same problem, and this is what I do,
> 
>   case $target in
> *-*-mingw*)
>   abs_top_srcdir=`cd $srcdir; pwd -W`
>   abs_top_builddir=`pwd -W`
>   ;;
> *)
>   abs_top_srcdir=`cd $srcdir; pwd`
>   abs_top_builddir=`pwd`
>   ;;
>   esac
> 
> It's probably not correct,
It isn't.

You will want to use $build instead of $target

>  but it works.
If the only purpose is to access the toplevel source directory inside of
configure, all this is superfluous. You can simply use $srcdir inside of
configure.ac instead.

If the purpose is to propagate the toplevel directory to files in
subdirs through AC_SUBST, using abs_*dir's render configured build-trees
to be non-relocatable (Consider logging in into the same account from
different nfs-mount-points, say /nfs//)

If the purpose is to access files inside of the source-tree from inside
of Makefile.am, there are better ways of doing so (using relative paths,
being composed of $(subdir) and $(top_srcdir))

You are probably using an antiquated autoconf. Modern autoconf's already
support abs_top_srcdir and abs_top_builddir.

Ralf





___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers

[Ralf Corsepius]

On Fri, 2007-03-30 at 00:16 +0100, Keith Marshall wrote:
> On Thursday 29 March 2007 18:04, Ralf Wildenhues wrote:
> > * Chris Johns wrote on Thu, Mar 29, 2007 at 08:45:36AM CEST:
> > > The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and
> > > that has broken MinGW based cross-compilers using autoconf packages
> > > in MSYS.
> >
> > Not the one I'm using.  Debian testing's cross compiler package
> > i586-mingw32msvc-gcc chmod's its executable output to 0755.
> 
> With respect, that's not relevant.  Chris is not referring to a *nix 
> hosted compiler targetting MinGW; he's struggling with a Win32 hosted 
> RTEMS compiler suite, targetting various embedded platforms, if I 
> understand him correctly.  Of course, his following statement is 
> potentially confusing...
> 
> > > RTEMS uses AC_LINK_IFELSE and MinGW cross-compilers fail this test.
> 
> ...for in reality, MinGW has nothing to do with this, beyond his having 
> used it to compile his Win32 hosted cross-compiler in the first place.
> 
> > Which compiler and version is used?
> >
> > > A MinGW compiler cannot set an execute bit on an executable as
> > > Windows provides no support for it.
> >
> > But a cross compiler knows that it's a cross-compiler on a unixy
> > $build, so in principle it could try, no?
> 
> But this isn't a Unixy $build; it's a Win32 $build, with MSYS providing 
> the (GNU bash) shell environment, to run the configure scripts.
> 
> > Anyway, let's see what 
> > compilers don't do this in practice, theory counts little here.
> >
> > > Is the 'test -x' suitable for MSYS and a cross-compiler ?
> >
> > Well, this is AFAIK the first bug report about this.
> 
> Well, that doesn't make it any less of a bug, and it's been introduced 
> only as of autoconf-2.61.
> 
> Chris has already raised this issue, on the MSYS list:
> http://thread.gmane.org/gmane.comp.gnu.mingw.devel/2290/focus=3922
> 
> IMO, it is completely proper for the MSYS implementation of bash to 
> return false, for `test -x' on any file which isn't runnable on the 
> Win32 platform. 
Pardon, but I have to disagree on this. A file being marked as
"executable" doesn't mean it can be run in this particular native
environment. 

It means a file is meant to be run from the file system it is located
on.

This is of particular importance for cross-compilers: They produce
executables to be run elsewhere. I.e. these files need to be marked
'+x'ed. [1]

>  Here, we can't simply lie by setting an executable bit 
> on a file's directory entry, for there isn't any such bit; executable 
> status is accorded only to files having an appropriate file name 
> extension; like it or not, that's just the way it is, in the M$ world.  
> (Actually, MSYS extends this by also according executable status to 
> shebanged scripts).
Well, as I read all this, MSYS's "test" diverges from a *nix's "test"[2]

Ralf

[1] A classical situation to meet this is a networked mounted filesystem
being shared between several OS and using a cross compiler on one system
to build executables for other OS.

[2] An RTEMS user using a Cygwin host, reported this issue also to occur
on Cygwin when using a FAT32 filesystem but not to occur with an NTFS
filesystem.




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Why "unknown"?

[Ralf Corsepius]

On Tue, 2007-02-13 at 10:12 -0600, Matthew Woehlke wrote:
> Warren Young wrote:
> > Matthew Woehlke wrote:
> >> Andreas Schwab wrote:

> Going back to the original question, I think a good thing to ask is 
> 'what does the triple mean'? Although I think the answer to the original 
> question is "because that's what 'uname -p' reports", isn't it?

Have a look into config.guess and config.sub.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: "has changed since the previous run"

[Ralf Corsepius]

On Thu, 2007-02-01 at 21:29 -0500, DJ Delorie wrote:
> > I am observing the "CFLAGS" issue in newlib-1.15.0 with gcc < 4.2, but I
> > am not observing this issue with gcc >= 4.2.
> > 
> > So, I am suspecting the "CFLAGS" leak in GCC's toplevel Makefile.in
> > triggering the ".. change since previous run", might have been fixed in
> > GCC since then.
> 
> Our tree is based on gcc 4.2, though.  And we appear to have the
> separate cache patch.  What platform are you testing with?

Cross building Fedora -> various rtems targets toolchains, consisting of
gcc-core/gcc-g++/newlib, building one-tree style.

>   We see the
> bug mostly on Solaris and Cygwin.
Hmm, ... 


To work around this issue with gcc-4.1.x (I do not use it for gcc-4.0.x
nor gcc-4.2), I am using this hack below.

diff -uNr gcc-4.1.1.orig/Makefile.in gcc-4.1.1/Makefile.in
--- gcc-4.1.1.orig/Makefile.in  2006-04-04 23:03:05.0 +0200
+++ gcc-4.1.1/Makefile.in   2007-01-31 09:37:58.0 +0100
@@ -329,9 +329,9 @@
 # CFLAGS will be just -g.  We want to ensure that TARGET libraries
 # (which we know are built with gcc) are built with optimizations so
 # prepend -O2 when setting CFLAGS_FOR_TARGET.
-CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET)
+CFLAGS_FOR_TARGET = $(strip -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET))
 SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@
-CXXFLAGS_FOR_TARGET = $(CXXFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET)
+CXXFLAGS_FOR_TARGET = $(strip $(CXXFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET))
 LIBCFLAGS_FOR_TARGET = $(CFLAGS_FOR_TARGET)
 LIBCXXFLAGS_FOR_TARGET = $(CXXFLAGS_FOR_TARGET) -fno-implicit-templates
 LDFLAGS_FOR_TARGET = 


Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: "has changed since the previous run"

[Ralf Corsepius]

On Thu, 2007-02-01 at 13:49 -0500, DJ Delorie wrote:
> > Not any more.  Nowadays every configured subdirectory gets its own cache.
> 
> Hmmm... I thought our source tree was up to date.  I wonder if that
> would "solve" our problem.
FWIW: 

I am observing the "CFLAGS" issue in newlib-1.15.0 with gcc < 4.2, but I
am not observing this issue with gcc >= 4.2.

So, I am suspecting the "CFLAGS" leak in GCC's toplevel Makefile.in
triggering the ".. change since previous run", might have been fixed in
GCC since then.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Problems upgrading

[Ralf Corsepius]

On Sun, 2007-01-28 at 16:57 -0500, Thomas Dickey wrote:
> On Sun, 28 Jan 2007, Ralf Wildenhues wrote:
> 
> > Hello Skip,
> >
> > * Skip Kimpel - Magicgate Software, Inc. wrote on Sat, Jan 27, 2007 at 
> > 08:30:53PM CET:
> >>
> >> I have version 2.57 installed on my system and I would like to upgrade
> >> to 2.61.. What do I need to do this?
> >
> > Hmm.  You could download
> > 
> 
> He could try.  But most of the releases of autoconf since 2.52 have had
> interdependencies with specific versions of automake.   Perhaps he doesn't
> need that much entertainment...
Simply install autoconf and automake to a prefix != /usr or /usr/local
and the issue is gone.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: order to run autotools

[Ralf Corsepius]

On Tue, 2007-01-23 at 11:17 -0500, Bob Rossi wrote:
> On Tue, Jan 23, 2007 at 05:15:00PM +0100, Ralf Corsepius wrote:
> > On Tue, 2007-01-23 at 10:59 -0500, Bob Rossi wrote:
> > > Hi,
> > > 
> > > I'm learning a lot about the autotools. I want to say thanks to the list
> > > for teaching me so much! 
> > > 
> > > I have a quick question, I run the autotools in this order,
> > 
> > With recent auto*tools, you should use autoreconf instead
> 
> I'm using recent tools. I should use autoreconf instead of autoconf even
> if I'm autoconf'ing for the first time? I do this when I check out the
> tree for the first time.

Yes.

autoreconf -fi
or
autoreconf -fis

should do exactly what you want.

> > >   aclocal -I config
> > >   autoconf -f
> > >   autoheader
> > >   automake -a
> > > when I do an out-of-tree configure it works fine, but when I do the make
> > > I get,
> > >   cd ../cgdb && /bin/bash
> > >   /home/bob/rcs/svn/cgdb/cgdb.testsuite/cgdb/config/missing --run
> > >   autoheader
> > > 
> > > Am I doing something wrong or is this expected?
> > The former, the order is wrong. But unless you're using ancient
> > auto*tools, you're better off using autoreconf.
> 
> What's the order supposed to be then?
I intentionally did not answer this, because there is no "100% bullet-proof" 
answer.

In most (90%) cases, when using ancient autotools it was:

aclocal
automake
autoconf
autoheader

> > Besides this, there is a (AFAICT, yet undiscovered) bug somewhere, which
> > occasionally triggers "seemingly spurious" autoheader runs.
> 
> I can reproduce this every time.
Did you use autoreconf?

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: order to run autotools

[Ralf Corsepius]

On Tue, 2007-01-23 at 10:59 -0500, Bob Rossi wrote:
> Hi,
> 
> I'm learning a lot about the autotools. I want to say thanks to the list
> for teaching me so much! 
> 
> I have a quick question, I run the autotools in this order,

With recent auto*tools, you should use autoreconf instead

>   aclocal -I config
>   autoconf -f
>   autoheader
>   automake -a
> when I do an out-of-tree configure it works fine, but when I do the make
> I get,
>   cd ../cgdb && /bin/bash
>   /home/bob/rcs/svn/cgdb/cgdb.testsuite/cgdb/config/missing --run
>   autoheader
> 
> Am I doing something wrong or is this expected?
The former, the order is wrong. But unless you're using ancient
auto*tools, you're better off using autoreconf.

Besides this, there is a (AFAICT, yet undiscovered) bug somewhere, which
occasionally triggers "seemingly spurious" autoheader runs.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: why does autoconf check for all these extra compilers?

[Ralf Corsepius]

On Fri, 2006-07-28 at 11:14 +0200, Stepan Kasal wrote:
> Hello,

> > the configure script checks for a whole bunch of extra compilers.
> > What's up with that?
> 
> That is a limitation of libtool: it searches for a compiler for each
> language it supports, even though your project doesn't use eg.
> Fortran.  This is fixed in libtool 2.0.  Takes some time, but should
> be otherwise harmless.
It isn't harmless. The libtool-1.x implementation bogusly and silently
picks up the native toolchain's language specific frontend if a
cross-compiler's language's frontend is not available.

Ralf






___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Installing a directory

[Ralf Corsepius]

On Fri, 2006-06-30 at 14:38 +0200, erik wikstrom wrote:
> I'm in the process of migrating a small project to the 
> autoconf-framework and I'm almost done. The only thing left to fix is 
> the installation (make install). The application consists of an binary 
> executable file and a directory of images used by the executable. The 
> binary is installed as correctly but I can't figure out how to install 
> the directory with the images (should go into $PREFIX/share/appname). 
> When I try to run make install it fails with "/usr/bin/install: 
> `./images/' is a directory" which is true.
This is an automake question.

> How do I tell install that it's supposed to install a directory, is it 
> even possible?

Yes.

If you have contents to populate the directory, then the directory will
be automatically created:

e.g. something like this should work:
imagesdir = $(pkgdatadir)/images
images_DATA = xxx.jpg yyy.jpg
EXTRA_DIST = xxx.jpg yyy.jpg

If you don't have contents, then you can trigger automake to create the
dir with something similar to this:

imagesdir = $(pkgdatadir)/images
images_DATA =

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: possibly undefined macro: AC_PROG_LIBTOOL (was: (no subject))

[Ralf Corsepius]

On Mon, 2006-06-26 at 19:39 +, Harlan Stenn wrote:
> Clarification:
> 
> > >   first, run aclocal, it should install the AC_PROG_LIBTOOL macro to
> > > aclocal.m4.
> > >   Then run autoconf.
> > 
> > autoreconf does this.
> 
> autoreconf runs aclocal is what I meant.
> 
> On the machines where this apparently works, AC_PROG_LIBTOOL is in
> aclocal.m4, but on subdirs where it does not work, AC_PROG_LIBTOOL is
> *not* in aclocal.m4
How do you invoke the subdir configure scripts from inside of your
toplevel configure script?

Can you post the output of running
autoreconf -fv

from the toplevel source dir?

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: GNU Autoconf test version 2.59d available

[Ralf Corsepius]

On Tue, 2006-06-06 at 14:00 +0200, Stepan Kasal wrote:
> Hello Paul and Ralves,
> 
> the change discussed here was triggered by problems with Solaris'
> make.
> 
> I agree that the Automake manual could mention this bad scenario,
> perhaps something like:
> ``Avoid files with names identical to shell builtins or basic
> commands; during a VPATH build, Solaris' @command{make} would then
> make unwanted replacements in the commands text, yielding very
> puzzling results.  For example, no check script should be named
> @command{test}.''
> 
> OTOH, the recommendation in doc/install.texi could be perhaps more
> grained.  The problem is not that gmake is the only one working, the
> problem is that Solaris' make is extremely evil.  (Do I understand
> correctly that BSD make is not rewriting the commands?)
> 
> The wording could be along this:
> 
> ``The VPATH build should generally work with all make
> implementations.  Getting this right is tremendously tricky, though:
> in particular, the misfeatures of Solaris' @command{make} cause
> biggest troubles.  On the other hand, the most reliable (and most
> tested) is GNU make---try it if the VPATH build is not behaving
> well.''
Well, ... gmake is not the only "make" that might support proper VPATH
builds - It is just one case which does what automake assumes, it could
well be the only existing make implementation which currently do so,
but ... this doesn't mean it is, nor what will be valid in 5 years from
now.

The sub-sentence I consider to be wrong is this:

  INSTALL now suggests VPATH builds (e.g., "sh ../srcdir/configure")
  only if you use GNU make.

"VPATH builds using gmake are supposed to be safe" 
or 
"VPATH builds using Solaris make only work for a subset of class", would
be true.

@Ralf.W: Yes, I haven't checked what has changed in autoconf's sources,
but should there now be any AC_*-check in autoconf, I consider this to
be a bug. 

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: GNU Autoconf test version 2.59d available

[Ralf Corsepius]

On Tue, 2006-06-06 at 02:22 -0700, Paul Eggert wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> 
> > => If automake doesn't hold what it promises, it's a bug in automake
> 
> At the very least there is a documentation problem in Automake,
> because nowhere does it say that you can't have a test named 'test' --
> a situation that caused coreutils 'make check' to fork-bomb as described in
> <http://lists.gnu.org/archive/html/bug-coreutils/2006-06/msg00033.html>.
#8-) Never call a check program "test" - This should be a programming
beginner's knowledge ;-)

> Perhaps that problem could be worked around by changing all the
> makefiles that Automake generates, so that they somehow quote every
> word like "test" and "export" and etc., so that Solaris VPATH 'make'
> doesn't expand them.  However it's not obvious to me how to do that
> portably and reliably.  (And the resulting makefiles would be much
> harder to read.)
Implement an AM_CHECK_MAKE (or similar) to check if the make in use is
able to handle VPATHS as part of automake.
If all else fail, blacklist Solaris make for use with automake.

> >> We intend to suggest to end-users to use GNU make for
> >> VPATH builds;
> > If you make gmake mandatory for VPATH
> 
> The new wording isn't intended to make gmake mandatory;
As I read it, it's what effectively what it says.

As a consequence of this, it would only be logic to reflect this
behavioral change into automake, which would render many things in
automake much easier.

The next logic step would be to make bash mandatory for autoconf ...

Do you now sense the irrationality of your approach?

>  it is merely
> intended as advice to users who are typically not experts in these
> matters.  GNU make is the safest, as a rule, since it gets used the
> most in practice by Autoconf and Automake users.
Wrong. This is not autoconf's task, therefore you are in error to let
autoconf take care of it.

If automake doesn't work with VPATH's but gmake, automake should
implement this feature. 

Or, if this problem is limited to a subset of applications, these
applications should check for gmake.  

>   Other 'make'
> implementations might also work, but the rules for when they work and
> when they don't are too complicated to shoehorn into INSTALL.

So you agree, that making bash mandatory for autoconf is tremendous
simplification?

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: GNU Autoconf test version 2.59d available

[Ralf Corsepius]

On Tue, 2006-06-06 at 08:29 +0200, Ralf Wildenhues wrote:
> Hi Ralf,
> 
> * Ralf Corsepius wrote on Tue, Jun 06, 2006 at 05:44:00AM CEST:
> > On Mon, 2006-06-05 at 23:15 +0200, Ralf Wildenhues wrote:
> > > GNU Autoconf test version 2.59d is now available.
> > > 
> > > This is a beta release, intended to be largely identical to 2.60,
> > > to be released very soon, if no unexpected issues turn up.  So test it
> > > now, use it with your code, and report any remaining issues, please!  
> > > 
> > > The important changes since 2.59c are listed below, but two changes
> > > introduced earlier, in version 2.59c, require special attention:
> > > 
> > > * Some directory variables have been added, and others adjusted to
> > >   changes in the GNU Coding Standards.  If your package expands
> > >   '$datadir', '$infodir', or '$mandir' anywhere, you need to check your
> > >   package, and possibly adjust it accordingly.  The URL to the older
> > >   NEWS entries below, and the FAQ node 'Defining Directories' in the
> > >   manual have more information.
> > Hmm, I can't find this helpful, because
> 
> What exactly can you not find helpful?
OK, I assume I need to be more direct: I consider this to a severe
regression in autoconf and to be harmful to automake.


>   What are you referring to here?
> 
> > a) Makefiles are not autoconf's business.
> 
> We haven't changed much since 2.59c wrt. makefiles.
Then it's my fault of not having noticed this regression, earlier.

>   If you are using
> Automake, the changed directory variables (assuming you are referring to
> them) will be picked up automatically.  If you are using hand-written
> Makefile.in's, config.status will warn you for files you have not
> adjusted.
IMO, you are overengineering a problem from the wrong side.

If automake requires gmake for VPATH builds, then automake is in trouble
and automake will have to cope with it.

autoconf has no way to know what kind of problem a configure script is
trying to with. It doesn't know if it is going to generate Makefiles
from automake generated Makefile.ins, manually written GNUmakefiles,
Solaris Makefiles, BSD-make Makefiles, or if it generating any Makefile
at all, nor if/how a developer is trying to cope with VPATHS.

(Consider autoconf generating a "build-script" written in an arbitrary
scripting language).

> > b) Over the years, a tremendous amount of effort had been invested into
> > non-gmake VPATH support in automake. If something has crept into
> > automake that makes gmake necessary for VPATH-builds, I'd call this an
> > automake regression.
> 
> Nothing has changed here or crept in, except gained knowledge: things
> can go horribly wrong even without any Automake regression:
> http://lists.gnu.org/archive/html/bug-coreutils/2006-06/msg00033.html
This might apply to coreutils and further packages, but not depending on
gmake is on automake's list of objectives. 

=> If automake doesn't hold what it promises, it's a bug in automake and
automake's problem, not autoconf's problems, nor autoconf's task to deal
with it.

> > I recommend to reconsider this change.
> 
> Which change?  We intend to suggest to end-users to use GNU make for
> VPATH builds;
This is what I consider to be stupid. If you make gmake mandatory for
VPATH, you should ditch large parts of automake at the same time.

>  we should suggest to developers to write Makefile.am for
> portable make, however.  Would you agree with that?
No, I disagree. IMO, you are approaching the problem from the wrong
side.


Ralf





___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: GNU Autoconf test version 2.59d available

[Ralf Corsepius]

On Mon, 2006-06-05 at 23:15 +0200, Ralf Wildenhues wrote:
> GNU Autoconf test version 2.59d is now available.
> 
> This is a beta release, intended to be largely identical to 2.60,
> to be released very soon, if no unexpected issues turn up.  So test it
> now, use it with your code, and report any remaining issues, please!  
> 
> The important changes since 2.59c are listed below, but two changes
> introduced earlier, in version 2.59c, require special attention:
> 
> * Some directory variables have been added, and others adjusted to
>   changes in the GNU Coding Standards.  If your package expands
>   '$datadir', '$infodir', or '$mandir' anywhere, you need to check your
>   package, and possibly adjust it accordingly.  The URL to the older
>   NEWS entries below, and the FAQ node 'Defining Directories' in the
>   manual have more information.
Hmm, I can't find this helpful, because

a) Makefiles are not autoconf's business.

b) Over the years, a tremendous amount of effort had been invested into
non-gmake VPATH support in automake. If something has crept into
automake that makes gmake necessary for VPATH-builds, I'd call this an
automake regression.

I recommend to reconsider this change.

Ralf




___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf