Re: checking for Berkley db 4.2 --> 4.3 upgrade

[Mike Castle]

In article <[EMAIL PROTECTED]>, Sam Steingold  <[EMAIL PROTECTED]> wrote:
>Berkley db changed prototypes for functions that are struct members.
>how do I check for that?

The official word from Sleepycat is that it's much better to statically
link against a known version of BDB that you ship with your package.  This
is one of the first things they mentioned in the recently created
berkeley-db newsgroup.

Evolution now ships with a specific BDB, as does nvi, to give two examples
of packages that follow this policy.

mrc


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

Re: enable/disable configure options for subpackages

[Stepan Kasal]

Hello,

On Tue, Jul 26, 2005 at 08:55:30PM -0400, Bob Rossi wrote:
> Does autoconf
> only pass the explicit arguments down to the lower confurations? or if I
> have a --enable-shared=no defaulted option, would that work?

it passes the options as they were given on the cmdline.
So if you don't give an option explicitely, a subconfigure can have
different default than the upper package.

> On Fri, Jul 15, 2005 at 12:14:44PM +0200, Stepan Kasal wrote:
> > Of course some hacks are possible:
> > 1) fiddle with ac_args before AC_OUTPUT.
> >Of course this solution may easily break with future versions of 
> > autoconf.
> > 
> > 2) Read what AC_CONFIG_SUBDIRS does (how it propagates the arguments), and
> >do the same in configure.ac
> > 
> > 3) Simply call the embedded configure, and add features from
> >AC_CONFIG_SUBDIRS only when someone asks for it.
...
> These answers are all very helpful. However, I'm wondering if there is a
> simple way of sending the --disable-shared option to AC_CONFIG_SUBDIRS
> in a way that will be good with future versions of autoconf.

I don't know about any documented way.  Any of the above options can be simple.

> Just wondering if this feature is supported by autoconf?

That's the hard part.
No, I don't think this is available from documented options.
Autoconf and, more importantly, its documentation would have to be enhanced
to support this.  Do you feel like writing a patch to this effect?

But a simple hack is much simpler.

And remember, the developpers run autoconf to build the tarball.  The users
should just build from this tarball, without any need for Autotools installed.
So it doesn't mind _that_ much if you are not portabale to other versions of
Autoconf.

Have a nice day,
Stepan


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

Checking for interpreter libraries

[Tommy Nordgren]

I want to find out if there is any autoconf macros for checking for  
the presence of various scripting
language interpreters, and the libraries for extending/embedding  
them. I want to check for as
many as possible and reasonable of the scripting languages supported  
by Swig, and compile and

link against those avilable, but in particular Perl and Python.
I also need to find out about compiler and linker options necessary  
for linking against each library,

and validate that they are not mutually exclusive.
I want any useful suggestion on doing this.

PS I'm a newbie with the GNU Autotools

"Home is not where you are born, but where your heart finds peace" -
Tommy Nordgren, "The dying old crone"



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

Re: Checking for interpreter libraries

[Stepan Kasal]

Hello,

On Wed, Jul 27, 2005 at 01:21:14PM +0200, Tommy Nordgren wrote:
> I want to find out if there is any autoconf macros for checking for  
> the presence of various scripting language interpreters, and the
> libraries for extending/embedding them.

I don't think there is an instant support for this.

> [...] in particular Perl and Python.

Gnumeric, the GNU spreadsheet, supports scripting in both perl and python,
thus the autodetection in its configure.in might inspire you.
Download it from:

http://cvs.gnome.org/viewcvs/gnumeric/configure.in?rev=.


Then there is macro AM_PATH_PYTHON in Automake, but I don't think it
deals with embedding.  Yet it might be inspiring.
(See file m4/python.m4 in the Automake source tree; currently, it is
identical as my /usr/share/aclocal-1.9/python.m4 from Automake 1.9.6.
There was no non-trivial change since the release 1.9.4.)

Have a nice day,
Stepan Kasal


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

Re: checking for Berkley db 4.2 --> 4.3 upgrade

[Sam Steingold]

> * Mike Castle <[EMAIL PROTECTED]> [2005-07-26 23:52:30 -0700]:
>
> In article <[EMAIL PROTECTED]>, Sam Steingold  <[EMAIL PROTECTED]> wrote:
>>Berkley db changed prototypes for functions that are struct members.
>>how do I check for that?
>
> The official word from Sleepycat is that it's much better to statically
> link against a known version of BDB that you ship with your package.

this is not related to my question.

> This is one of the first things they mentioned in the recently created
> berkeley-db newsgroup.

what newsgroup?

> Evolution now ships with a specific BDB, as does nvi, to give two examples
> of packages that follow this policy.

I have my source file that relies on certain BDB features that are
different in different BDB versions, so my code should be different
depending on what BDB version it is being linked against - statically or
dynamically.
How does their build process decide which version of code to use?
Right now, I have an autoconf test that produces a CPP "#define" that
decides what code to use.

What are you suggesting instead?

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
  
  
Lottery is a tax on statistics ignorants.  MS is a tax on computer-idiots.



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

Re: [gettext] changequote considered harmful

[Bruno Haible]

Stepan Kasal wrote:
> changequote is consider risky:

It works fine for me.

> Attached please find a proposed patch.

> -changequote(,)dnl
> -typedef int array [2 * (__GNU_GETTEXT_SUPPORTED_REVISION(0) >= 1) - 1];
> -changequote([,])dnl
> +typedef int array [[2 * (__GNU_GETTEXT_SUPPORTED_REVISION(0) >= 1) - 1]];

This is unmaintainable: It mixes two different syntaxes in the same line of
code, namely C and autoconf. The same problem also exists when it mixes sh
and autoconf syntax (think of the brackets used in case statements and in sed
expressions).
  - When I'll want to add another array declaration to the code snippet the
next time, I'll most probably forget to double the brackets. And I will
search for 5 minutes why the macro doesn't behave as expected.
  - I want to be able to copy & paste C code snippets and shell commands
from and to autoconf macros. Having to scan the entire code, character
by character, for autoconf trigraphs and for [] is not welcome.

Bruno



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

Quieten move-if-change?

[Ben Elliston]

move-if-change currently outputs " is unchanged" when it does nothing.  
This
adds undue noise in GCC builds.  Would it be possible to give it more natural
behaviour like mv(1) and output nothing, regardless of whether it moves the 
file?

Ben


signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: enable/disable configure options for subpackages

[Bob Rossi]

> > On Fri, Jul 15, 2005 at 12:14:44PM +0200, Stepan Kasal wrote:
> > > Of course some hacks are possible:
> > > 1) fiddle with ac_args before AC_OUTPUT.
> > >Of course this solution may easily break with future versions of 
> > > autoconf.
> > > 
> > > 2) Read what AC_CONFIG_SUBDIRS does (how it propagates the arguments), and
> > >do the same in configure.ac
> > > 
> > > 3) Simply call the embedded configure, and add features from
> > >AC_CONFIG_SUBDIRS only when someone asks for it.
> ...
> > These answers are all very helpful. However, I'm wondering if there is a
> > simple way of sending the --disable-shared option to AC_CONFIG_SUBDIRS
> > in a way that will be good with future versions of autoconf.
> 
> I don't know about any documented way.  Any of the above options can be 
> simple.
> 
> > Just wondering if this feature is supported by autoconf?
> 
> That's the hard part.
> No, I don't think this is available from documented options.
> Autoconf and, more importantly, its documentation would have to be enhanced
> to support this.  Do you feel like writing a patch to this effect?
> 
> But a simple hack is much simpler.

Well, I modified the configure script that came with readline to set the
default for shared libs to be NULL. This solves my problem. However, if
you could guide me in a general purpose way, I would not mind adding a
feature like this to autoconf.

> And remember, the developpers run autoconf to build the tarball.  The users
> should just build from this tarball, without any need for Autotools installed.
> So it doesn't mind _that_ much if you are not portabale to other versions of
> Autoconf.

Yeah, this goes double for me, since I put the autoconf files in CVS.

Thanks for all your help,
Bob Rossi


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

Re: Mac OS X library path woes / issues / complaints

[Noah Misch]

On Tue, Jul 26, 2005 at 02:57:29PM -0400, tom fogal wrote:
> Of course, the user has the option of specifying
> LDFLAGS="/opt/local/lib" (or whatever) on their ./configure line, and
> then the configure script finishes. I am of the opinion (and correct me
> if I'm wrong) that unless the user jumped through special hoops when
> compiling/installing software, they should not have to jump through
> special hoops for other software to utilize that install. Arguably

The portable way to configure a package that uses another package installed with
--prefix=$other is `./configure CPPFLAGS=-I$other/include LDFLAGS=-L$other/lib'.

Perhaps INSTALL should document that invocation pattern.  Even so, the need is
common enough to justify providing a shorthand.  I do have a solution in mind.
I hope to be able to contribute it real soon now.

> On the other hand, I don't know how to work around OS X's strange
> linker and unconfigurable default search paths. It seems very strange
> to me that the Mac folk would design it this way; could someone please
> point out what I'm missing?

Facilities like /etc/ld.so.conf are the exception, and one needs access to root
to use them where they do exist.  Passing -I and -L via CPPFLAGS and LDFLAGS is
the standard solution.

Your configure script could itself try adding -L/opt/local/lib.  That would
accommodate your Darwinports users.


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

Re: Mac OS X library path woes / issues / complaints

[Bob Friesenhahn]

On Wed, 27 Jul 2005, Noah Misch wrote:


On Tue, Jul 26, 2005 at 02:57:29PM -0400, tom fogal wrote:

Of course, the user has the option of specifying
LDFLAGS="/opt/local/lib" (or whatever) on their ./configure line, and
then the configure script finishes. I am of the opinion (and correct me
if I'm wrong) that unless the user jumped through special hoops when
compiling/installing software, they should not have to jump through
special hoops for other software to utilize that install. Arguably


The portable way to configure a package that uses another package installed with
--prefix=$other is `./configure CPPFLAGS=-I$other/include LDFLAGS=-L$other/lib'.

Perhaps INSTALL should document that invocation pattern.  Even so, the need is
common enough to justify providing a shorthand.  I do have a solution in mind.
I hope to be able to contribute it real soon now.


It is easy for a configure script to extend CPPFLAGS and LDFLAGS 
itself based on the prefix but this can cause problems for the user 
since then the user loses control over the header and linking search 
path ordering.  It is important to ensure that the person doing the 
install retains control.


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


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