Re: Automake 1.16 build failure

2018-02-27 Thread Andreas Schwab
On Feb 27 2018, Mathieu Lirzin  wrote:

> What is the Perl version used?

5.18.2

> Can you open a bug report on  for this issue?

Done.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



Automake 1.16 build failure

2018-02-26 Thread Andreas Schwab
$ make -j4
  GEN  bin/automake
  GEN  bin/aclocal
  GEN  t/ax/shell-no-trail-bslash
  GEN  t/ax/cc-no-c-o
  GEN  runtest
  GEN  doc/aclocal.1
  GEN  doc/automake.1
  GEN  lib/Automake/Config.pm
  GEN  t/ax/test-defs.sh
  GEN  bin/aclocal-1.16
  GEN  bin/automake-1.16
  GEN  doc/aclocal-1.16.1
  GEN  doc/automake-1.16.1
help2man: can't get `--help' info from automake-1.16
Try `--no-discard-stderr' if option outputs to stderr
Makefile:3694: recipe for target 'doc/automake-1.16.1' failed
make: *** [doc/automake-1.16.1] Error 255
make: *** Waiting for unfinished jobs

$ ./pre-inst-env automake-1.16 --help
"none" is not exported by the List::Util module
Can't continue after import errors at 
/home/abuild/rpmbuild/BUILD/automake-1.16/bin/automake-1.16 line 76.
BEGIN failed--compilation aborted at 
/home/abuild/rpmbuild/BUILD/automake-1.16/bin/automake-1.16 line 76.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



Re: dist-xz compression level

2010-04-12 Thread Andreas Jellinghaus
Am Montag 12 April 2010 20:31:22 schrieb Ralf Wildenhues:
> My idea would be to implement this for master, and revert the recent
> xz -9 patch on branch-1.11.  Comments, criticism?

if the environment variables can be used to set the compression,
that is perfect for me. why write your own code, when the environment
will be accepted automatically?

but some documentation would help users I think.
(also some man pages don't document these environment options,
at least in the versions I have, but strings indicate they exist...)

Regards, Andreas




Re: dist-xz compression level

2010-04-12 Thread Andreas Jellinghaus
Am Sonntag 11 April 2010 21:37:13 schrieb Andreas Jellinghaus:
> isn't xz extremely slw with -9?
> maybe it wasn't a bug, bit intentionally not used,
> as that huge extra amount of time doesn't result in
> that many bytes saved.
> 
> is the compression level configureable somehow?

I did two tests with medium size sources and xz -6 vs. xz -9
is not a big difference in speed or compression size.
so please ignore my comment.

Regards, Andreas




Re: dist-xz compression level

2010-04-11 Thread Andreas Jellinghaus
isn't xz extremely slw with -9?
maybe it wasn't a bug, bit intentionally not used,
as that huge extra amount of time doesn't result in
that many bytes saved.

is the compression level configureable somehow?

Regards, Andreas




Re: unconditional version of EXTRA_DIST

2010-03-04 Thread Andreas Jellinghaus
Am Donnerstag 04 März 2010 03:31:04 schrieb Ralf Wildenhues:
> > ah. ok, so back to the drawing board for my plan with
> > optional documentation (see the thread a week ago or so).
> 
> You can use either of
> - wildcards,
>EXTRA_DIST = pattern*
> 
> - automake conditionals,
>if COND
>EXTRA_DIST += files...
>endif
> 
> - or plain old configure substitutions for variable content in
> EXTRA_DIST.
>EXTRA_DIST = file @list_of_files@ $(more_files)

ok,thanks. will try wildcard.
"*html" as patter will also work, if there is not even a single
html file?

Andreas




Re: unconditional version of EXTRA_DIST

2010-03-03 Thread Andreas Jellinghaus
Am Mittwoch 03 März 2010 20:32:53 schrieb Ralf Wildenhues:
> Hello Andreas,
> 
> * Andreas Jellinghaus wrote on Wed, Mar 03, 2010 at 02:11:52PM CET:
> > I'm told EXTRA_DIST files are optional - automake
> > will include them if they exist, but also go on,
> > if those files do not exist.
> 
> No, that is not true.  Just try
>   EXTRA_DIST = does-not-exist
> 
> and 'make dist' will fail.

ah. ok, so back to the drawing board for my plan with
optional documentation (see the thread a week ago or so).

Thanks, Andreas




unconditional version of EXTRA_DIST

2010-03-03 Thread Andreas Jellinghaus
I'm told EXTRA_DIST files are optional - automake
will include them if they exist, but also go on,
if those files do not exist.

so what do I use to include some file in the distribution,
but not have automake do anything with it (change/install/..)?

so far my Makefile.am uses EXTRA_DIST in some places,
but I want automake to fail if the files are not there.
(the files are not used by anything on unix/linux/gnu/mingw,
for example "Makefile.mak" files for building with visual stdio/c).

dist_DATA or something like that?

Thanks, Andreas




create libraries with libtool, but don't install *.la files?

2010-02-24 Thread Andreas Jellinghaus
Hi,

the combination autoconf/automake/libtool
makes it quite easy to create shared libraries.
but how can I install the file created as a single *.so
file, but without any *.la file etc.

the shared libraries we create implement a fixed plugin
interface thus they don't need the normal versioning
shared libraries have. also applications will only
load the shared libraries using the plugin mechanism,
so neither dynamic not statically linkinging in the
library with application code is required.

can you give an example how to archive this?

Thanks, Andreas




Re: advice for pre-generating documentation

2010-02-11 Thread Andreas Jellinghaus
Ah, thanks. I didn't know about EXTRA_DIST.

Is there some mechanism I can put a wildcard into automake
files? for example it would be easier to specify "*.html",
as the script downloads all wiki pages, and thus new pages
would be added automaticaly that way.

also I wonder:
what about builddir vs. sourcedir? how do you handle that?

if people have a tar.gz with pre-build documentation, it
is in sourcedir. if people checkout svn and build in a seperate
build root, the documentation is created in builddir.

does automake handle that automaticaly?

and is there a nice way to remove the documentation 
with "make clean" or "make distclean" if it was generated,
but not remove it if it comes from the tar.gz?
use the same if/else/endif around the CLEANFILES settings?

Thanks!

Regards, Andreas




advice for pre-generating documentation

2010-02-11 Thread Andreas Jellinghaus
Hi,

we generate some docs with doxygen, others with a shell
script using wget and xslt to download our wiki and
create local html files from that).

that mechanism is currently enabled with "--enable-doc",
off by default as it is time-consuming and usualy not
wanted.

the problem I have is this:
* I want people to checkout svn and compile and test the
  software without generating documentation.
* if people want the docs, they should be able to create
  them too.
* if I run "make distcheck", I want the existing documentation
  to be included in the tar.gz file.
* if I run "make maintainer-clean", I want generate documentation
  to be removed, so I can diff between a modified checkout and
  an unmodified svn checkout.

but our code to do all that is really ugly. so I wonder what the
best way to implement something like this is. can you give me an
advice?

from my point of view documentation is on the same level as
"configure" and "makefile.in" - something we don't keep in
svn, but generate as first step after the checkout and
then distribute as part of the tar.gz to users. is there
some hook I can use to run custom commands easily from
autoconf/make/libtool? maybe even in a way I can turn
it on? (thus generate documentation only if asked)

any better idea? thanks for your help.

Regards, Andreas
p.s. if you want to see the code we currently have:
svn co http://www.opensc-project.org/svn/openct/trunk
and look at the docs/ directory.




Re: problem --enable-shared and --enable-static together

2009-12-06 Thread Andreas Otto
Am Samstag 05 Dezember 2009 13:33:06 schrieb Ralf Wildenhues:
> Hello Andreas,
>
> besides answers already given:
>
> * Andreas Otto wrote on Fri, Dec 04, 2009 at 09:41:16AM CET:
> > as you see both *lo and *.o are created. the *.o are useless and just
> > extend the compiling time
> >
> > Q: what can I do to avoid build static libraries ...
>
> foo_LIBTOOLFLAGS = -tag=disable-static
>
> for a target 'foo'.
>
> > I use "../libmsgque/*.lo" for in-project libraray dependency to avoid to
> > link to my own shared libraray
>
> Sounds like you could profit from using convenience archives.

from the info page:


8.3.5 Libtool Convenience Libraries
---

Sometimes you want to build libtool libraries that should not be
installed.  These are called "libtool convenience libraries" and are
typically used to encapsulate many sublibraries, later gathered into
one big installed library.

-> the problem is "not be installed"

the base library from my project is "libmsgque" and this library is
used for the following purpose:

1. installed as library 
2. used as base library for a language-extension library
3. used as base library for some test-tools.

for 2+3 I don't want to link again the shared libraray of "libmsgque"

>
> > 2. executables should build without library dependency. This mean that
> > if configured with "--enable-static" the static object files should be
> > used and if configureed without the shared object files should be used.
>
> Link the program against the library with -static.
>
> Hope that helps.
>
> Cheers,
> Ralf



Re: problem --enable-shared and --enable-static together

2009-12-06 Thread Andreas Otto
Am Samstag 05 Dezember 2009 13:33:06 schrieb Ralf Wildenhues:
> Hello Andreas,
>
> besides answers already given:
>
> * Andreas Otto wrote on Fri, Dec 04, 2009 at 09:41:16AM CET:
> > as you see both *lo and *.o are created. the *.o are useless and just
> > extend the compiling time
> >
> > Q: what can I do to avoid build static libraries ...
>
> foo_LIBTOOLFLAGS = -tag=disable-static

Q: what is foo?

I try "tclmsgque_LIBTOOLFLAGS" -> no change
I look into the "Makefile" and get

...
tclmsgque_la-context_tcl.lo: context_tcl.c
$(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile 
$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $
(CPPFLAGS) $(tclmsgque_la_CFLAGS) $(CFLAGS) -MT tclmsgque_la-context_tcl.lo -
MD -MP -MF $(DEPDIR)/tclmsgque_la-context_tcl.Tpo -c -o tclmsgq
ue_la-context_tcl.lo `test -f 'context_tcl.c' || echo 
'$(srcdir)/'`context_tcl.c
...
as you see only $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) are used 
->I'm confused
the info page speek about
...
   If `LIBRARY_LIBTOOLFLAGS' is not defined, the global
`AM_LIBTOOLFLAGS' variable is used instead.
...

about LIBRARY_LIBTOOLFLAGS well even the "LIBRARY" prefix does not work
->I'm more confused

than I try AM_LIBTOOLFLAGS

and get the following error...

/bin/sh ../../libtool --tag=CC -tag=disable-static  --mode=compile ccache gcc 
-std=gnu99 -DHAVE_CONFIG_H -I. -I../..   -D_DEBUG  -I./../libmsgque -
I/home/dev1usr/ext/x86_64-suse-linux/thread/include -DUSE_TCL_STUBS  -
DMQ_IGNORE_EXTERN -g -O3 -Wall -Wcast-align -Wstrict-prototypes -
fvisibility=hidden -g -O2 -pthread -MT tclmsgque_la-context_tcl.lo -MD -MP -MF 
.deps/tclmsgque_la-context_tcl.Tpo -c -o tclmsgque_la-context_tcl.lo `test -f 
'context_tcl.c' || echo './'`context_tcl.c
libtool: unrecognized option `-tag=disable-static'
libtool: Try `libtool --help' for more information.
make: *** [tclmsgque_la-context_tcl.lo] Fehler 1

after a look inti the info page I change "-tag" to "--tag" ..

next try

now it works ...

summary:

change:

foo_LIBTOOLFLAGS = -tag=disable-static

into

AM_LIBTOOLFLAGS = --tag=disable-static

than it is fine



>
> for a target 'foo'.
>
> > I use "../libmsgque/*.lo" for in-project libraray dependency to avoid to
> > link to my own shared libraray
>
> Sounds like you could profit from using convenience archives.
>
> > 2. executables should build without library dependency. This mean that
> > if configured with "--enable-static" the static object files should be
> > used and if configureed without the shared object files should be used.
>
> Link the program against the library with -static.
>
> Hope that helps.
>
> Cheers,
> Ralf



problem --enable-shared and --enable-static together

2009-12-04 Thread Andreas Otto

Hi,

  I have a project using together the both statements from above to configure.
  This project hase many different parts includig many shared libraries
  and executables.

  Now the problem.

  1. I have libraries which are only useful as "shared" libraries. this
 libraries are language extension used to dl-open by an programming
 language.

  these libraries should "not" build the "static" object files

example:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><
pkglib_LTLIBRARIES = tclmsgque.la

tclmsgque_la_SOURCES =  context_tcl.c  misc_tcl.c  msgque_tcl.c read_tcl.c 
send_tcl.c \
  config_tcl.c service_tcl.c msgque_tcl.h slave_tcl.c 
\
MqBufferS_tcl.c error_tcl.c

# use this if you want to include the libmsgque files into the tclmsgque 
libraray
tclmsgque_la_CFLAGS = -I$(srcdir)/../libmsgque $(TCL_INCLUDE_SPEC) 
$(TCL_CFLAGS) $(AM_CFLAGS) -DMQ_IGNORE_EXTERN
tclmsgque_la_LIBADD = ../libmsgque/*.lo

tclmsgque_la_LDFLAGS = -shared -module -avoid-version -no-undefined 
$(TCL_LIBADD)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

the following object files are created
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-rw-rw-r--  1 dev1usr users   1000  4. Dez 09:27 tclmsgque.la
-rw-rw-r--  1 dev1usr users323  4. Dez 09:27 tclmsgque_la-config_tcl.lo
-rw-rw-r--  1 dev1usr users 154528  4. Dez 09:27 tclmsgque_la-config_tcl.o
-rw-rw-r--  1 dev1usr users326  4. Dez 09:27 tclmsgque_la-context_tcl.lo
-rw-rw-r--  1 dev1usr users 120656  4. Dez 09:27 tclmsgque_la-context_tcl.o
-rw-rw-r--  1 dev1usr users320  4. Dez 09:27 tclmsgque_la-error_tcl.lo
-rw-rw-r--  1 dev1usr users  96240  4. Dez 09:27 tclmsgque_la-error_tcl.o
-rw-rw-r--  1 dev1usr users317  4. Dez 09:27 tclmsgque_la-misc_tcl.lo
-rw-rw-r--  1 dev1usr users  94800  4. Dez 09:27 tclmsgque_la-misc_tcl.o
-rw-rw-r--  1 dev1usr users332  4. Dez 09:27 tclmsgque_la-MqBufferS_tcl.lo
-rw-rw-r--  1 dev1usr users  97688  4. Dez 09:27 tclmsgque_la-MqBufferS_tcl.o
-rw-rw-r--  1 dev1usr users323  4. Dez 09:27 tclmsgque_la-msgque_tcl.lo
-rw-rw-r--  1 dev1usr users 103328  4. Dez 09:27 tclmsgque_la-msgque_tcl.o
-rw-rw-r--  1 dev1usr users317  4. Dez 09:27 tclmsgque_la-read_tcl.lo
-rw-rw-r--  1 dev1usr users 113008  4. Dez 09:27 tclmsgque_la-read_tcl.o
-rw-rw-r--  1 dev1usr users317  4. Dez 09:27 tclmsgque_la-send_tcl.lo
-rw-rw-r--  1 dev1usr users 122192  4. Dez 09:27 tclmsgque_la-send_tcl.o
-rw-rw-r--  1 dev1usr users326  4. Dez 09:27 tclmsgque_la-service_tcl.lo
-rw-rw-r--  1 dev1usr users  88400  4. Dez 09:27 tclmsgque_la-service_tcl.o
-rw-rw-r--  1 dev1usr users320  4. Dez 09:27 tclmsgque_la-slave_tcl.lo
-rw-rw-r--  1 dev1usr users  93392  4. Dez 09:27 tclmsgque_la-slave_tcl.o
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

as you see both *lo and *.o are created. the *.o are useless and just
extend the compiling time

I use "../libmsgque/*.lo" for in-project libraray dependency to avoid to
link to my own shared libraray

Q: what can I do to avoid build static libraries ...


2. executables should build without library dependency. This mean that
if configured with "--enable-static" the static object files should be used
and if configureed without the shared object files should be used.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
brain_SOURCES = brain.c
brain_CFLAGS = -I../theLink/libmsgque -I$(BRAIN_HOME)/include -
DMQ_LINK_WITH_LIBRARY_OBJECT_FILES

if HAS_STATIC
LIBMSQUE = ../theLink/libmsgque/*.o
else
LIBMSQUE = ../theLink/libmsgque/*.lo
endif

brain_LDADD = -lz -lbz2 -lrt -lm -lc $(LIBMSQUE) 
$(BRAIN_HOME)/lib/libtokyocabinet.a
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

I need a HELPER called HAS_STATIC defined in configure.in with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
AM_CONDITIONAL([HAS_STATIC], [test "$enable_static" = "yes"])
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Q: Is this OK or is something better is possible ?


mfg

  Andreas Otto


question to the subpackage feature

2009-11-25 Thread Andreas Otto

Hi,

 I have integrated an subpackage into an already existing package
 everything works well but one problem still exists

  the debugging feature is turned on in the toplevel package with
  --enable-symbols and in the subpackage with --enable-debug
  some kind of translation is necessary

-> how I can do this ?

  in generell all commandline arguments from the toplevel
  package are send to the subpackage even if the arguments
  have no meaning in the subpackage

-> how I solve this issue ?


example:

toplevel ...
+ bash ./configure --prefix=/tmp/libmsgque-install --enable-symbols --enable-
tcl --enable-cxx --enable-threads

subpackage ...
=== configuring in tokyocabinet-1.4.39 
(/home/dev1usr/Project/libbrain/tokyocabinet-1.4.39)
configure: running /bin/sh ./configure --disable-option-checking '--
prefix=/tmp/libmsgque-install'  '--enable-symbols' '--enable-tcl' '--ena
ble-cxx' '--enable-threads' 'CC=ccache gcc' 'CXX=ccache g++' --cache-
file=/dev/null --srcdir=.


in addition: confiure --help does only show the help-page from the
toplevel package and does not provide any information from the
subpackage ...



mfg

  Andreas Otto


Re: OS independent build results

2009-11-01 Thread Andreas Otto
Hi,

  this is my solution:

  this add a new target ".vpath_hook" to the build environment and this target
  copy the files/directories listed in "VPATH_FILES" from the src into the
  build environment. the "copy" is necessary because tools like "JAR"
  expect the files in the "build" directory. ".vpath_hook" is the FIRST
  target in BUILT_SOURCES to garantee that the copy is done before
  any furter action are done.


1. acinclude.m4

#
# SC_SET_VPATH_HOOK --
#
#   add support for VPATH build
#
# Arguments:
#   none
#   need variable "VPATH_FILES" be defined
#
# Results:
#
#   Add a new variable VPATH_HOOK/CLEANUP/DIST  to automake
#
#

AC_DEFUN([SC_SET_VPATH_HOOK], [
AC_MSG_CHECKING([add VPATH hook])
AC_SUBST([VPATH_HOOK], ['@if test ! -f .vpath_files -a "$(srcdir)" != "." 
; then (cd "$(srcdir)" && cp -r $(VPATH_FILES) "$(abs_builddir)";) && touch 
".vpath_files" && chmod -R u+w $(VPATH_FILES) && echo "VPATH copy"; else true; 
fi && touch ".vpath_hook"'])
AC_SUBST([VPATH_HOOK_CLEANUP], ['-rm -f .vpath_hook; test -f .vpath_files 
&& rm -fr .vpath_files $(VPATH_FILES)'])
AC_SUBST([VPATH_HOOK_DIST], ['-rm -f $(distdir)/.vpath_hook'])
])

2. example java Automake.am:

...
#
## VPATH setup

.vpath_hook:
$(VPATH_HOOK)

VPATH_FILES = javamsgque javamsgque_MqS.h javamsgque_MqBufferS.h 
javamsgque_MqS_WAIT.h javamsgque.jar

BUILT_SOURCES = .vpath_hook $(mqs_DATA) javamsgque_MqS.h 
javamsgque_MqBufferS.h
MAINTAINERCLEANFILES = $(BUILT_SOURCES) javamsgque_MqS_WAIT.h 
javamsgque/*.class
...

distclean-local:
$(VPATH_HOOK_CLEANUP)

dist-hook: $(MQS_MAIN)
$(VPATH_HOOK_DIST)
mkdir "$(distdir)/javamsgque"
chmod u+w "$(distdir)/javamsgque"
cp javamsgque/*.class "$(distdir)/javamsgque"
chmod u+w $(distdir)/javamsgque/*.class



!important! is that "make clean" should not clean the *.class files.
I use the "MAINTAINERCLEANFILES" to clean this files also



OS independent build results

2009-10-25 Thread Andreas Otto

Hi,

  currently I try to improve my build environment. I want to add "OS" 
  independent build results like

java "class" files or mono "clr" libraries/excutable 

  into the distribution

  1) the problem is the VPATH build. the files from above are
  in the "srcdir" and not in the "builddir" (1'st location)

  2) if one of the "prerequisite" file are touched
(java -> *.java", mono -> *.cs")
 the "new" class or clr file(s) are in the "builddir" (2'nd location)
after the build

  -> now I have 2 locations from which the "dist" or a other command
 like the java "jar" can take the files

  3) only for case 2) the VPATH build have to clean up the files

  4) for a very special vase VB.NET CLR files can only be compiled
on a special OS (Windows). A non-Windows OS should use
the dist files and print a WARNING message if a build have to be 
done


is a solution available?


one solution would be that vor a VPATH build I can specify a set
of dirs/files (in a variable) to COPIED first from the srcdir
into the builddir, these copied files have to be removed in a
"distclean" -> attention the copy have only be done if the
target of the same name is not available



mfg

  Andreas Otto


builddir question

2009-10-23 Thread Andreas Otto

Hi,

  is a "builddir" other than "." possible ?



mfg

  aotto1968


Re: integration of perl with automake

2009-10-20 Thread Andreas Otto
Am Dienstag 20 Oktober 2009 21:07:35 schrieb Ralf Wildenhues:
> * Andreas Otto wrote on Tue, Oct 20, 2009 at 08:53:14AM CEST:
> > Am Dienstag 20 Oktober 2009 08:27:01 schrieb Ralf Wildenhues:
> > > > distclean-local:
> > > > test -f Net-Msgque/.distclean && rm -fr Net-Msgque
> > >
> > > Won't that also remove files from your package iff source and build
> > > tree coincide?
> >
> > I use the flag file "Net-Msgque/.distclean" to distinguish the VPATH
> > build from the non VPATH build. this flag is only set in the directory I
> > copied from the source into the build tree and clean act on this flag
>
> OK, but then 'make distclean' wouldn't remove the files it should
> remove, if source and build tree coincide, no?
>
> Cheers,
> Ralf


Hi,


$(PERLMAKEFILE): $(PERLDEPEND) Makefile.am
-test ! -d Net-Msgque && cp -pr $(srcdir)/Net-Msgque . && \
chmod -R u+w Net-Msgque && touch Net-Msgque/.distclean
cd Net-Msgque && @PERL@ Makefile.PL $(PERLCONFIG)

  non VPATH -> build-tree == source-tree
=> no copy and no flag "Net-Msgque.distclean"
=> no distclean remove

  VPATH -> build-tree != source-tree
   => copy from Net-Msgque done and flag "Net-Msgque/.distclean" set
   => distclean remove performed

is this does not explain your problem
than I don't understand what you mean


mfg

  Andreas Otto


Re: integration of perl with automake

2009-10-19 Thread Andreas Otto
Am Dienstag 20 Oktober 2009 08:27:01 schrieb Ralf Wildenhues:
> Hello Andreas,
>
> thanks for sharing your solution.  A couple of comments:
>
> * Andreas Otto wrote on Mon, Oct 19, 2009 at 12:20:26PM CEST:
> > if USE_PERL
> >
> > PERLMAKEFILE  = Net-Msgque/Makefile
> > PERLDEPEND= Net-Msgque/Makefile.PL Net-Msgque/typemap Net-
> > Msgque/lib/Net/Msgque.pm
> > PERLCONFIG=   PREFIX=$(prefix) \
>
> It would be prudent to quote $(prefix), too.
>
> >   INC="-Wall -I. -I../$(top_srcdir)/src" \
> >   OBJECT="\$$(O_FILES) ../$(top_builddir)/src/.libs/*.o"
> >
> > install-exec-local:
> > cd Net-Msgque && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$(DESTDIR)
> > install
>
> Likewise, I'd quote $(DESTDIR) here, or even better, omit
> DESTDIR=$(DESTDIR) unless Net-Msgque/Makefile initializes it.
>
> > uninstall-local:
> > rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/Net/Msgque.pm
>
> Please remove the slash between $(DESTDIR) and $(prefix) here and in
> following lines.  Otherwise you risk breaking the installation on w32
> with --prefix=C:/foo and empty DESTDIR.  Also, again it would be prudent
> to quote the $(DESTDIR)$(prefix) part of the strings.
>
> > rm -f
> > $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.so
> > rm -f
> > $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.bs
> > rm -f
> > $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/autosplit.ix
> > rm -f
> > $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/.packlist
> > rm -f $(DESTDIR)/$(prefix)/lib/*/*/*/perllocal.pod
> > rm -f $(DESTDIR)/$(prefix)/share/man/man3/Net::Msgque.3
> >
> > distclean-local:
> > test -f Net-Msgque/.distclean && rm -fr Net-Msgque
>
> Won't that also remove files from your package iff source and build tree
> coincide?

Hi,

  I add your suggestions ...

I use the flag file "Net-Msgque/.distclean" to distinguish the VPATH build
from the non VPATH build. this flag is only set in the directory I copied
from the source into the build tree and clean act on this flag


mfg

  Andreas Otto




Re: integration of perl with automake

2009-10-19 Thread Andreas Otto
Hi,

  this is my solution:
  I have coosen a Makefile.am wrapper and the perl-extension is in
  a subdirectory of the wrapper. I changed the extension-name to
  Net::Msgque (as requested by the perl community)
  the automake configuration is complete (as of my needs) including
  a VPATH build and including the "distclean" check.
  PERL - MakeMaker does not support a VPATH build but a work-
  around is possible to copy the perl extension directory into the
  build directory. This have to be cleaned-up in distclean-local.

  now the Makefile:
  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
if USE_PERL

PERLMAKEFILE  = Net-Msgque/Makefile
PERLDEPEND= Net-Msgque/Makefile.PL Net-Msgque/typemap Net-
Msgque/lib/Net/Msgque.pm
PERLCONFIG=   PREFIX=$(prefix) \
  INC="-Wall -I. -I../$(top_srcdir)/src" \
  OBJECT="\$$(O_FILES) ../$(top_builddir)/src/.libs/*.o"

if DEBUG
PERLCONFIG+= OPTIMIZE=-g
endif

$(PERLMAKEFILE): $(PERLDEPEND) Makefile.am
-test ! -d Net-Msgque && cp -pr $(srcdir)/Net-Msgque . && chmod -R u+w 
Net-Msgque && touch Net-Msgque/.distclean
cd Net-Msgque && @PERL@ Makefile.PL $(PERLCONFIG)

all-local: $(PERLMAKEFILE)
cd Net-Msgque && $(MAKE) $(AM_MAKEFLAGS)

clean-local: $(PERLMAKEFILE)
cd Net-Msgque && $(MAKE) $(AM_MAKEFLAGS) clean

install-exec-local:
cd Net-Msgque && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$(DESTDIR) install

uninstall-local:
rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/Net/Msgque.pm
rm -f 
$(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.so
rm -f 
$(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.bs
rm -f 
$(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/autosplit.ix
rm -f 
$(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/.packlist
rm -f $(DESTDIR)/$(prefix)/lib/*/*/*/perllocal.pod
rm -f $(DESTDIR)/$(prefix)/share/man/man3/Net::Msgque.3

distclean-local:
test -f Net-Msgque/.distclean && rm -fr Net-Msgque

endif

EXTRA_DIST = \
Net-Msgque/ppport.h \
Net-Msgque/Msgque.xs \
Net-Msgque/lib/Net/Msgque.pm \
Net-Msgque/Makefile.PL \
Net-Msgque/README \
Net-Msgque/t/Net-Msgque.t \
Net-Msgque/Changes \
Net-Msgque/MANIFEST \
Net-Msgque/typemap
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


mfg

  Andreas Otto



integration of perl with automake

2009-10-15 Thread Andreas Otto

Hi,

  to build a perl extension it's best to use the perl build-system based on

perl Makefile.PL

   the command create a Makefile in the same directory of Makefile.PL self
   and in the toplefel-position "perlmsgque/Makefile".
   I can use this makefile in an automake build environment using

SUBDIRS += perlmsgque

   from the toplevel

  now the problem. a "make clean" clean the file perlmsgque/Makefile. this
  is coded in the "Makefile.PL" create Makefile

  1.   I need automake code to check if "perlmsgque/Makefile" is avilable
and build this makefile again if missing (after make clean) or extend
the toplevel Makefile to do a 
(cd perlmsgque;perl Makefile.PL)
after all "make clean" was done

  2. related to this problem Is the initial build of the "perlmsgque/Makefile"
currently I use the autoconf to do the "perl Makefile.PL" but I thing
it should be better done on need in the toplevel makefile.


I hope this is not to complicated

-> thanks for help


mfg

  aotto1968
  






I need a hint to integrate a php-extension build into an existing automake

2009-10-01 Thread Andreas Otto
Hi,

  I want to add a "php" extension into an allready existing project creating
  various extensions to other languages as well

  I use automake/autoconf for build top-level project. My new "php"
  extension has the name "phpmsgque" build in the subdirectory
  of the same name. The sudirectory is filled with all files necessary 
  to build a php extension

  php requires the following steps to build an extension,

  1. change into the phpmsgque directory
  2. run the tool:  
phpize 
-> this tool create a complete autoconf build environment
including "configure.in"
  3. run the command:
./configure --enable-phpmsgque
-> this create a "Makefile"
  4. now use make  for build

now my problem:

1. while running the toplevel "automake" (or autoreconf)  I would like to run
the tool "phpize" in the phpmsgque subdirectory to create the php build
   environment. I have the "Makefile.am" (not used in the php build) to
   add instructions to link the both build environments.
2. while run toplevel "configure" I would like to run the "configure"
script in the "phpmsgque" subdirectory as well

so I looking for an integration of 2 build environments

the second question is easy to solve I use

AC_CONFIG_SUBDIRS([phpmsgque])

in the toplevel configure.in but the php build  environment has
"no" AM_INIT_AUTOMAKE to get a "full" integration

I use the docs from automake info pages to get the info
from above to integrate two packages:




using C# in automake

2009-05-24 Thread Andreas Otto

Hi,

  I want to create an language binding for a "C" libraray 

this mean I have as input an file called "csmsgque.cs"
and get as output an "csmsgque.dll" on unix

My current makefile looks like:

=
.dll.cs:
mkdir .libs
$(CSCOMP) -v -unsafe -nologo -out:./.libs/$@ -target:library $<

pkglib_LIBRARIES = csmsgque.dll

csmsgque_dll_sources = csmsgque.cs
=

but I get the following error

csmsgque/Makefile.am:17: `csmsgque.dll' is not a standard library name
csmsgque/Makefile.am:17: did you mean `libcsmsgque.a'?



I need docs on howto create NON-C language project which create
language specific executables or libraries into automake

I want to create this libraries into the ".libs" directory as "libtool" does
and finally I want to install these files into the "pkglibdir" / "bindir" 
directory for install ..
...
and I want that the language specific source files "*.cs"
be included into the dist
...
and I want that this is tested during distcheck as well

  -> lot of stuff, but a template would be fine for other users as well



mfg

  Andreas Otto




Re: cross-compiling on 64 to 32-bit Linux

2009-05-24 Thread Andreas Schwab
Jan Engelhardt  writes:

>>needs to use $CC/$CXX anyway.
>
> CCLD/CXXLD.

Which default to $CC/$CXX anyway.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: cross-compiling on 64 to 32-bit Linux

2009-05-24 Thread Andreas Schwab
Bruno Haible  writes:

>   - The -m32 flag has to be passed as part of both CC / CXX and LDFLAGS.

That should not be necessaray, since any command that uses $LDFLAGS
needs to use $CC/$CXX anyway.

>   - The -m64 flag is the default on bi-arch Linux systems.

This is wrong.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




shared libraries with used defined extension

2009-05-19 Thread Andreas Otto

Hi,

   Unix/Linux is using *.so as shared libraray extension ...
   Windows is using *.dll as shared libraray extension...

   Python requires the postfix *.pyd as shared library extension


   Question: it is possible to use it own shared library extension

   using automake, autoconf, libtool ...


mfg

  Andreas Otto




binary distribution build with automake

2009-05-08 Thread Andreas Otto
Hi,

  I missing one target in automake to create a binary distribution

Reason:

1. the default prefix is "/usr/local" -> thats ok
2. this prefix is required for libraray "rpath" feature -> thats ok
3. to buid and install a sw in "/usr/local" is a problem because it
belons to "root" and not to the "user" ans should not be
used in "normal" sw development

what I want

1. a new target "binary-dist"
2. to create a binary distribution:
"$(PACKAGE)-$(PACKAGE_VERSION)-$(build).tar.gz"
-> I choose "build" as hw/os identification string
3. able to use "--prefix" as system-directory !without! 
installation requirement


mfg

  Andreas Otto




Re: rebuilding following a change in prefix?

2009-05-08 Thread Andreas Schwab
Jan Engelhardt  writes:

> Well, automake (unfortunately?) does not currently issue a recompile
> when the compiler command changed.
> It would be really cool to have that, though.

But that should be optional.  I don't want to do a complete rebuild just
because I want to do a quick recompile of a single object file with
different options.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: rebuilding following a change in prefix?

2009-05-08 Thread Andreas Schwab
Adam Mercer  writes:

> I have noticed some strange behaviour with the build system on a
> project I am working on, consider the following:
>
> $ ./configure --prefix=/path/1
> $ make
> $ make install
> $ ./configure --prefix=/path/2
> $ make
> $ make install

I'd suggest using separate build directories for each build.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Setting shared lib version not functioning

2009-05-06 Thread Andreas Schwab
John Calcote  writes:

> One thing that bothers me a little is that we never really did solve
> Gerald's original problem. He said his library was created just fine when
> he was passing 2:0:0, but when he switched to 2:0:1, it created a library
> with a version number of 1:1:0. Now, why would Libtool do this? Granted,
> he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, either. So
> why did Libtool convert it to 1:1:0?

For the linux way of library versioning the library suffix is computed
as (current-age).age.revision, thus 2:0:1 maps to 1.1.0.  A libtool
version of 1:1:0 whould map to 1.0.1.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Example on JNI compilation

2009-04-20 Thread Andreas Otto
Am Samstag 18 April 2009 23:08:58 schrieb LCID Fire:
> I'm currently stuck with compiling a JNI library, which java does not
> recognize. I'm not too sure about what options I have to provide to
> automake and which are already builtin. Does anybody know an example of
> how a jni lib is built using automake?

Hi,

  in my project:   

http://libmsgque.sourceforge.net/
 
  you can find a implementation useable as template

  1. download the sources
  2. go into the "javamsgque" directory
  3. don't forget to add the autoconf macros for JNI
from the "m4" subdirectory and the "acinclude.m4" file


mfg

  Andreas Otto




problem to create a "noinst_LTLIBRARIES" shared libraray

2009-04-03 Thread Andreas Otto
Hi,

 I currently writing a java JNI extension used only for local "check" and
 this library should *not* be installed. 

  The problem is that I  need a shared library for dlopen using java

file: TestMain.java
===
public abstract class TestMain extends MqS.Main {

  static {
System.loadLibrary("javatestmsgque");
  }
...
===

but automake/libtool only create a *static* library even if the "_LDFLAGS"
-module is used

file: Makefile.am
===
noinst_LTLIBRARIES = libjavatestmsgque.la
libjavatestmsgque_la_SOURCES =  test_java.c TestMain.h
libjavatestmsgque_la_CFLAGS = -I$(top_srcdir)/src $(AM_CFLAGS)
libjavatestmsgque_la_LIBADD = ../src/libmsgque.la
libjavatestmsgque_la_LDFLAGS = -module
===

this are the "static "libraries created using the "noinst_" prefix

buildsubdirectory: .libs
===
-rw-r--r--  libjavatestmsgque.a
lrwxrwxrwx  libjavatestmsgque.la -> ../libjavatestmsgque.la
-rw-r--r--  libjavatestmsgque_la-test_java.o
===

using the "pkglib_" or the "lib_" prefix I get the shared libraries

subdirectory: .libs
==
lrwxrwxrwx  libjavatestmsgque.la -> ../libjavatestmsgque.la
-rw-r--r-- 1libjavatestmsgque.lai
-rw-r--r-- 1libjavatestmsgque_la-test_java.o
lrwxrwxrwx  libjavatestmsgque.so -> libjavatestmsgque.so.0.0.0
lrwxrwxrwx  libjavatestmsgque.so.0 -> libjavatestmsgque.so.0.0.0
-rwxr-xr-x 1libjavatestmsgque.so.0.0.0
===

Question: what can I do to get a shared LTLIBRARIES using the "noinst"
prefix ?


every answer is welcome ...




Spurious testsuite failures

2009-04-01 Thread Andreas Schwab
I'm getting several failures in the automake testsuite, for example:

FAIL: libtool.test (exit: 1)


/home/andreas/src/osc/automake/BUILD/automake-1.10b/tests:/opt/kde3/bin:/home/andreas/bin/ccache:/home/andreas/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin:/sbin:/usr/local/m68k-linux/gcc/bin:/usr/local/m68k-linux/bin:/usr/local/ia64-linux/bin:/usr/lib/git
libtool: running libtool --version
ltmain.sh (GNU libtool) 2.2.6
Written by Gordon Matzigkeit , 1996

Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
=== Running test ./libtool.test
++ pwd
/home/andreas/src/osc/automake/BUILD/automake-1.10b/tests/libtool.dir
+ cat
+ :
+ :
+ :
+ :
+ aclocal-1.10b -Werror -Wno-syntax -I 
/home/andreas/src/osc/automake/BUILD/automake-1.10b/tests/../m4 -I 
/usr/local/share/aclocal -I /usr/share/aclocal
aclocal: couldn't open directory `/usr/local/share/aclocal': No such file or 
directory
+ Exit 1
+ set +e
+ exit 1
+ exit 1
+ exit_status=1
+ cd /home/andreas/src/osc/automake/BUILD/automake-1.10b/tests
+ case $exit_status,$keep_testdirs in
+ test 0 '!=' 0
+ echo ': exit 1'
: exit 1
+ exit 1


The problem is that /usr/share/aclocal/dirlist contains the
(non-existing) directory /usr/local/share/aclocal.  Normally aclocal
would ignore such a directory, but by adding it explicitly with -I
aclocal now complains.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: blank line following trailing backslash

2009-01-26 Thread Andreas
Am Montag, 26. Januar 2009 schrieb Ralf Wildenhues:
> Hello Andreas,
>
> * Andreas wrote on Sun, Jan 25, 2009 at 06:42:52PM CET:
> > fileA.c \
> > fileB.c \
> > fileC.c
>
> [...]
>
> > This is not nice so I thought well let's add a backslash after the
> > last file and add an empty line at the end. Then there's no need to
> > modify the fileC line and everybody just adds a line to the list. This
> > can be resolved. But automake doesn't like this at all. Even though it
> > is clearly visible that this is not wrong it complains. It doesn't
> > even warn about this it produces an error.
>
> Jan already provided a way around this.  Here's why automake warns about
> it at all: it is not portable to have a backslash followed by a blank
> line, as some make implementations are rather unpredictable with it:
> <http://www.gnu.org/software/autoconf/manual/html_node/Backslash_002dNewlin
>e_002dNewline.html>
> <http://www.gnu.org/software/autoconf/manual/html_node/Backslash_002dNewlin
>e-Comments.html>
>
> Hope that helps.
>
> Cheers,
> Ralf

Ok, ich verstehe. Ich muß zugeben meine Make und Automake Kenntnisse sind eher 
gering, aber könnte man nicht eine Warnung ausgeben und den letzten Backslash 
entfernen? Immerhin erkennt man ihn, es sollte also möglich sein ihn auch weg 
zu nehmen

Andreas




blank line following trailing backslash

2009-01-25 Thread Andreas
Hello everybody,

I just had an ingenious idea to limit conflicts in versioning systems.

When you specify a list of files for a rule you put every file in a line like 
this.

fileA.c \
fileB.c \
fileC.c

now if 2 independent people add another file fileD and fileE to that list you 
have a conflict because both of them modify the line with fileC.c to add the 
necessary backslash.

This is not nice so I thought well let's add a backslash after the last file 
and add an empty line at the end. Then there's no need to modify the fileC 
line and everybody just adds a line to the list. This can be resolved. But 
automake doesn't like this at all. Even though it is clearly visible that 
this is not wrong it complains. It doesn't even warn about this it produces 
an error.

I think this is not nice. Is there a way around this problem? Can I do 
something to make all file list entries identical? Or can I tell automake to 
ignore this or only produce a warning?

Thanks a lot

Andreas




Re: Portable suffix rules question

2009-01-02 Thread Andreas Schwab
Jan Engelhardt  writes:

> I reckon that %-style suffix rules (e.g. "%.o: %.c") are rather 
> unportable, but I wonder how the old-fashioned suffix rule for
>
> %.1: %.1.php
>
> would look like.

There is none.  A suffix rule can contain at most two periods, so the
closest you can get is this:

.php:

Andreas.

-- 
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: automake manual: distclean

2008-11-26 Thread Andreas Schwab
Jan Engelhardt <[EMAIL PROTECTED]> writes:

> This is not quite portable -- unless GNU find, which implies a 
> path of "." if nothing else is specified, Solaris's explicitly requires 
> a path to find. It should therefor read
>
>  distcleancheck_listfiles = \
>find . -type f -exec sh -c 'test -f $(srcdir)/{} || echo {}' ';'

This isn't quite portable either.  POSIX only requires that find -exec
substitutes in arguments consisting of exactly {}.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Generating Autotools files without autoreconf

2008-10-01 Thread Andreas Schwab
Roberto Bagnara <[EMAIL PROTECTED]> writes:

> In other words, we would need something that acts like autoreconf except
> for the fact that it would not attempt to build configure from configure.ac.

$ AUTOCONF=true autoreconf ...

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Problems with conditional sources

2008-08-25 Thread Andreas Schwab
John Calcote <[EMAIL PROTECTED]> writes:

> Andreas Schwab wrote:
>> John Calcote <[EMAIL PROTECTED]> writes:
>>
>>> Make is a two-pass utility. The first pass completely assimilates all
>>> macro data specified in the Makefile. THEN, the second pass generates
>>> the rule dependency tree.
>>
>> This is not true.  Variable refences in target and dependency lists are
>> expanded when they are read.  Any later redefinition will not change
>> them.
>>
>> Andreas.
>>
>
> This is only true if you use ':=' assignment.

You are mistaken.  RTFM.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Problems with conditional sources

2008-08-25 Thread Andreas Schwab
John Calcote <[EMAIL PROTECTED]> writes:

> Make is a two-pass utility. The first pass completely assimilates all
> macro data specified in the Makefile. THEN, the second pass generates
> the rule dependency tree.

This is not true.  Variable refences in target and dependency lists are
expanded when they are read.  Any later redefinition will not change
them.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Problems with conditional sources

2008-08-25 Thread Andreas Schwab
David Sveningsson <[EMAIL PROTECTED]> writes:

> Hi, I am having some problems with conditional sources. This is what I
> have in Makefile.am:
>
> lib_LTLIBRARIES = libfoo.la
> libfoo_la_SOURCES = foo.cpp
> if WANT_BAR
>   libfoo_la_SOURCES += a.cpp
> else
>   libfoo_la_SOURCES += b.cpp
> endif
>
> AM_CPPFLAGS = -I${top_srcdir}/include
> libfoo_la_LDFLAGS = -version-info 0:0:0
>
> I have been reading both autoconf and automake manuals and as far as I can
> see the above should work. However the files (a.cpp or b.cpp) is always
> added at the bottom of the generated Makefile and are therefore not used
> in the compilation. No matter what I try I cannot get even the above code
> to generate a correct makefile but obviously I am doing something wrong.

Remove the indentation.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Warn: non-POSIX variable name

2008-08-19 Thread Andreas Schwab
Brian Dessent <[EMAIL PROTECTED]> writes:

> The difference with this method is that the values are computed once
> when configure is run, and then substituted into the Makefile when it is
> generated after configure has completed.  When you use $(shell ...) the
> value is not computed until you run make, and the result is not stored
> anywhere so it is recomputed each time that make is run.

Even worse, it is recomputed each time the variable is _used_, ie. for
every compilation job started by make.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: How can I change shared library's version number?

2008-06-06 Thread Andreas Schwab
"Steven Woody" <[EMAIL PROTECTED]> writes:

> When I use autoconf/automake with its integrated libtool to build a
> shared library, I got shared libraray named 'libfoo.so.0.0.0'.  I
> don't sure where the 0.0.0 comes from, and I don't like it.  How can I
> change it?  I searched info page but found no answer.

See (libtool)Versioning.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: bug in automake? Getting ARFLAGS to work...

2008-05-21 Thread Andreas Schwab
Ed Hartnett <[EMAIL PROTECTED]> writes:

> In order to build on AIX in 64-bit mode, I have to be able to set the
> ARFLAGS, but I can't get that to work. No matter what I do, automake
> ignores my ARFLAGS and just uses "cru".

This is a libtool issue, nothing to do with automake.  For whatever
reason, libtool is using AR_FLAGS, not ARFLAGS.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: build configuration help

2008-04-03 Thread Andreas Schwab
John Calcote <[EMAIL PROTECTED]> writes:

> The way you implement this is to use $(prefix)/lib, or $(libdir) in your
> -R option, which will resolve to the configured library installation
> directory - /home/bob/foo/lib. When you use -R like this, however, just
> realize that this binary can only be installed on this one non-standard
> location (it can still be installed in standard locations).

You can use -R '$ORIGIN/../lib' to make the binary relocatable.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: proper autotools ordering?

2008-02-25 Thread Andreas Schwab
[EMAIL PROTECTED] (Karl Berry) writes:

> I've been using aclocal - autoheader - automake - autoconf for years,
> but have no idea any more where I got that ordering.  I see that
> autoreconf runs autoconf before autoheader, and ah before am, so I
> suppose this is it:
> aclocal - autoconf - autoheader - automake.

There is no real dependency between autoconf/autoheader/automake.  The
only requirement is that aclocal is run before any of them, and
sometimes it has to be run twice if libtoolize enters the scene.

> Whatever the answer is, I suggest adding it to the manual(s).

The manual should recommend autoreconf if it doesn't already.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Forcing an AC_CHECK to fail

2007-10-20 Thread Andreas Schwab
"Michael B Allen" <[EMAIL PROTECTED]> writes:

> So how to do I preset a cache variable before running configure?

You can put it in the environment, or use config.site.  See
(autoconf)Site Defaults.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Forcing an AC_CHECK to fail

2007-10-20 Thread Andreas Schwab
"Michael B Allen" <[EMAIL PROTECTED]> writes:

> So is there a way to tell a specific check to fail?

You can preset the cache variable before running configure.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Makefile.am assistance

2007-10-19 Thread Andreas Schwab
NightStrike <[EMAIL PROTECTED]> writes:

> Ok.  I just tested your idea, and I am going to move all .a custom
> targets to a _DATA primary, and leave the _SCRIPTS primary for just
> the custom executable targets (like crt1.o, etc).

crt1.o is DATA as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: read-only git mirror of automake cvs repository

2007-10-08 Thread Andreas Schwab
Jim Meyering <[EMAIL PROTECTED]> writes:

> I admit it was took more than a few iterations to get it right.
> One of the big points was to realize that cvsps' cache was causing
> trouble.  So I'm careful to make git-cvsimport run cvsps in such a
> way that the cache can't interfere.
> One way to do that is to point HOME= at an empty directory
> for the git-cvsimport run.

I think you should be able to use '-p -x' to pass -x to cvsps.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: multi-line AC_SUBSTs as targets in Makefile.am

2007-10-08 Thread Andreas Schwab
William Pursell <[EMAIL PROTECTED]> writes:

> I'd like to get away from AC_SUBST_FILE, but I don't see a way
> around the manner in which automake is building the Makefile.
> Is there a way to construct a generic target via AC_SUBST?

How about using AM_CONDITIONAL instead?

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: strange choice of compiler on HP-UX

2007-09-26 Thread Andreas Schwab
[EMAIL PROTECTED] (Bob Proulx) writes:

> Since on HP-UX with the optional HP ANSI C compiler installed 'cc' is
> a symlink in /usr/bin and also /bin on HP-UX is a symlink to /usr/bin
> resulting in a single large bin directory with everything in it all in
> one place so it would be difficult to change this by adjusting PATH.

You are free to create your own directory.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: strange choice of compiler on HP-UX

2007-09-26 Thread Andreas Schwab
Joao Miguel Ferreira <[EMAIL PROTECTED]> writes:

> Question: How do I tell the tools to use only aCC for both types of
> files, when compiling on an HPUX (we also build on Linux/gcc and
> Solaris/gcc) ?

./configure CC=foo CXX=bar

> PS: the cc is a link in /usr/bin that point to /opt/ansic/bin/cc !!! I
> am not root of this system :-(

You don't need to be root to change PATH.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: ${} and $()

2007-08-17 Thread Andreas Schwab
Jan Engelhardt <[EMAIL PROTECTED]> writes:

> (And the stupid reply: am I on automake@gnu.org or [EMAIL PROTECTED] :-)

automake both about makefiles and configue scripts.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: ${} and $()

2007-08-17 Thread Andreas Schwab
Jan Engelhardt <[EMAIL PROTECTED]> writes:

> is there any real difference between $(var) and ${var}, and is the 
> latter as much POSIX as the first?

Depends on the context.  For a shell there is a big difference between
them.  When interpreted by make they are identical.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: multiple cpu's

2007-08-10 Thread Andreas Schwab
Bob Rossi <[EMAIL PROTECTED]> writes:

> Can automake take advantage of multiple cpu's?

This has nothing to do with automake.  Just use the appropriate switch
for make to enable parallel execution.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: PING: Automake list

2007-08-09 Thread Andreas Schwab
NightStrike <[EMAIL PROTECTED]> writes:

> Where should I look instead for automake archives?

Since the list is @gnu.org, you should be looking at lists.gnu.org.

(Also, Gmane is a good place to look.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: %-style pattern rules

2007-07-30 Thread Andreas Schwab
Lorenzo Bettini <[EMAIL PROTECTED]> writes:

> Ralf Wildenhues wrote:
>> Hello Lorenzo,
>>
>> * Lorenzo Bettini wrote on Fri, Jul 27, 2007 at 05:18:48PM CEST:
>>> and what if I need two files (with two different extensions) depend on
>>> a single file?
>>
>> That is not possible portably, i.e., with inference rules.  So either
>> you can just choose to rely on GNU make, or write one rule per instance.
>
> apart from multiple files, I also tried to update some Makefile.am as
> follows:
>
> SUFFIXES = .cc.html .cs.html .h.html
>
> .cs.cs.html:
>   $(CSHARP2HTML) -i $< -o $@

This is not a recognized suffix rule, you'll have to register the .cs
suffix manually.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Circular dependecy linker trouble

2007-06-08 Thread Andreas Schwab
Søren Boll Overgaard <[EMAIL PROTECTED]> writes:

> Framework code depends on services code and vice versa. 
> Linking fails to resolve dependencies. The linker command line 
> essentially looks like this:
>
> g++  -g -O2 ../src/framework/libframework.a ../src/services/
> liblmsservices.a  -o program main.o  -lpthread

Note that the command line as shown won't pull anything from the
archives, because at the time they are processed there are no unresolved
symbols yet (except for the symbol main).  You should always list the
libraries after the objects that reference symbols out of them.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: generated ChangeLog

2007-03-13 Thread Andreas Schwab
Stepan Kasal <[EMAIL PROTECTED]> writes:

>   if a projects wants to generate ChangeLog dynamicly, from a
> versioning system, by a make rule, how it can be done?
> If you write the rule for ChangeLog to Makefile.am, then Automake
> complains that the file does not exist at the time Automake is run.

If you use AUTOMAKE_OPTIONS = foreign then automake should not complain.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Desktop file and exec path

2007-02-08 Thread Andreas Schwab
Benoit Sigoure <[EMAIL PROTECTED]> writes:

> Although two ways of solving this issue have been proposed already, there is
> also another way out: using an AC_CONFIG_FILES.
>
> glpegsolitaire.desktop.in
> --
> [Desktop Entry]
> Name=Peg Solitaire
> Comment=A "Peg Solitaire" for Gnome
> [EMAIL PROTECTED]@
> Icon=glpegsolitaire.png
> Terminal=false
> Type=Application
> Categories=GNOME;Game;BoardGame
> StartupNotify=true
> --
>
> In your configure.ac:
> AC_CONFIG_FILES([path/to/glpegsolitaire.desktop])

Such substitutions only work correctly in makefiles, since they can expand
to references to other substituted variables that are supposed to be
recursively expanded as done by make.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Desktop file and exec path

2007-02-08 Thread Andreas Schwab
Enrico Sardi <[EMAIL PROTECTED]> writes:

> glpegsolitaire.desktop
> --
> [Desktop Entry]
> Name=Peg Solitaire
> Comment=A "Peg Solitaire" for Gnome
> Exec=glpegsolitaire
> Icon=glpegsolitaire.png
> Terminal=false
> Type=Application
> Categories=GNOME;Game;BoardGame
> StartupNotify=true
>
> --
>
> and I want that if  I give the command  "make install" the path in the
> Exec field will be replaced by the value of the $(datadir)  variable. Is
> this possible?

Use @DATADIR@ in glpegsolitaire.desktop.in and put this in your makefile:

glpegsolitaire.desktop: $(srcdir)/glpegsolitaire.desktop.in
sed 's:@DATADIR@:$(datadir):' $(srcdir)/glpegsolitaire.desktop.in > 
glpegsolitaire.desktop.in

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: adding libraries and header file directories

2006-11-09 Thread Andreas Schwab
"Jim Rainville" <[EMAIL PROTECTED]> writes:

> Doh! Sometimes I fail to see the forest for the trees. So I copied the
> link line and added the --perserve-dup-deps flag. Something weird
> happens here. It's cutting off a lot of the file names. I thought at
> first it was a copy and paste error but its not

It is almost certainly a paste error.

> [EMAIL PROTECTED] vlc-0.8.5]$ /bin/sh ./libtool --preserve-dup-deps
> --mode=link --tag=CC gcc -Wsign-compare -Wall -pipe -o vlc vlc -vlc.o
 ^^^
> src/libvlc.a -Wl,--start-group -lelem_chkpt_api -lelem_chmgmt_api
> -lelem_ core_api -lelem_mobj_api -lelem_fault_api -lelem_rel_api
  

etc.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: How do I get configuration files installed?

2006-10-27 Thread Andreas Schwab
Jim Lynch <[EMAIL PROTECTED]> writes:

> I'm trying to figure out how to add a file to be installed in
> $prefix/bin/lib.

Are you sure you want that and not $libdir or even $datadir?

> But when I put
> bin_SCRIPTS=bin/float.pl bin/work.pl bin/lib/cipher.txt
> in there, it simply puts ciper.txt in bin also.  How can I tell it that I
> want that file to end up in bin/lib?

binlibdir = $(bindir)/lib
binlib_DATA = bin/lib/cipher.txt

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: depcomp deficiency [was: m4-1.4.7 build feedback]

2006-09-28 Thread Andreas Schwab
Eric Blake <[EMAIL PROTECTED]> writes:

> If they really want to stop parsing options, and pass all remaining
> arguments to gcc, then they should be using -- between the options they
> give gcc and the remaining arguments that they pass unchanged.

Which unfortunately does not work since gcc interprets -- as an ambigous
abbreviation instead of the end-of-option-marker.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: depcomp deficiency [was: m4-1.4.7 build feedback]

2006-09-27 Thread Andreas Schwab
Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> The issue is
> much more special in this case: the FreeBSD compiler wrapper c89
> accepts the options
>   -MP -MD -MF -MT
>
> if they appear _after_ all the other command line arguments,

The wrapper probably just stops parsing options at the first non-option,
and passes all remaining arguments unchanged.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Forcing static link of libstdc++

2006-09-20 Thread Andreas Schwab
Mike Melanson <[EMAIL PROTECTED]> writes:

> If I install gcc 4.0.2 as a separate compiler on
> an older machine, I wonder if it will be an option to link to
> libstdc++.so.5?

That won't work.  The C++ runtime library is tightly coupled with the
compiler.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: convenience libraries & binary size

2006-08-01 Thread Andreas Schwab
Pieter Grimmerink <[EMAIL PROTECTED]> writes:

> 1. move all >200 sourcefiles back into a single directory...
> 2. stop using autotools, so we no longer need convenience libs to handle 
> subdirectories

You don't need convenience libraries to handle subdirectories.  Have you
tried subdir-objects?  (*Note (automake)Options::.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: aclocal.m4 using m4_include or inlining macros?

2006-07-05 Thread Andreas Vinsander
Andreas Vinsander wrote:
> Hi!
> 
> I just saw that aclocal v1.9.6 did something I don't understand the
> reason for.
> 
> When doing aclocal -I ../../build_tools/m4, I end up with a aclocal.m4
> file having a m4_include([../../build_tools/m4/somemacroiuse.m4])
> 
> But when doing aclocal -I /home/proj/standalone/HEAD/drat/build_tools/m4
> (actually the same directory as before but with an absolute path), I end
> up with aclocal.m4 containing the inlined macro instead of the include
> directive.
> 
> It still works fine, I am just curious to why this is happening.

Forget this, I should have done more extensive RTFM...
It's all in the info pages...

/Andreas





aclocal.m4 using m4_include or inlining macros?

2006-07-05 Thread Andreas Vinsander
Hi!

I just saw that aclocal v1.9.6 did something I don't understand the
reason for.

When doing aclocal -I ../../build_tools/m4, I end up with a aclocal.m4
file having a m4_include([../../build_tools/m4/somemacroiuse.m4])

But when doing aclocal -I /home/proj/standalone/HEAD/drat/build_tools/m4
(actually the same directory as before but with an absolute path), I end
up with aclocal.m4 containing the inlined macro instead of the include
directive.

It still works fine, I am just curious to why this is happening.

/Andreas




Re: How to build src/server and src/client separately?

2006-06-16 Thread Andreas Ntaflos
Mark, Ralf, 

thank you very much for your replies! Works fine now, just what I 
wanted.

Much appreciated!

Thanks, 

Andreas
-- 
Andreas "daff" Ntaflos 
Vienna, Austria 

GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


pgp6aXmAdIrhF.pgp
Description: PGP signature


How to build src/server and src/client separately?

2006-06-15 Thread Andreas Ntaflos
Hello list, 

I think this shouldn't be too difficult, but I couldn't find it in the 
automake manual (possibly because I don't know exactly what to look 
for).

My project consists of $(topdir)/src/server and $(topdir)/src/client. 
Issuing `./configure && make' in $(topdir) correctly builds server and 
client, two otherwise unrelated programs. 

I would like to be able to issue `make' to build both (current 
behaviour) as well as `make server' and `make client' to build them 
separately if I want to do so.

I'd appreciate it if anyone could point me to the right section in TFM 
or give me clues how to configure my project for the desired behaviour.

Thanks in advance!

Andreas
-- 
Andreas "daff" Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


pgparBUvbUMkS.pgp
Description: PGP signature


Re: mailing list administrivia (was: aclocal 1.9.6 and drive letters)

2006-06-01 Thread Andreas Büning
Bob Proulx schrieb:
> 
> Ralf Wildenhues wrote:
> > * Andreas Büning wrote:
> > > Some weeks ago I sent a mail to the automake-patches mailing list
> > > but it never appeared there. Then I tried the bug-automake
> > > mailing list. I checked the mailing list archives on lists.gnu.org
> > > my posting never appeared.
> >
> > That is weird, sounds like some spam filter gone too picky.
> > Bob, Stepan?
> 
> Your message to the automake list went through fine.  And all of the
> lists are configured virtually identically.  The spam filtering is
> identical between them although the list configurations are
> independent.
> 
> I looked through the spam trap archive and could not find any messages
> posted from your address.  I looked at the automake-patches list and
> you are subscribed there where puts your address in the whitelist.  No
> checking will be done and any mail with your from address will pass
> through without filtering.  On the bug-automake list I see your
> address in the whitelist which means messages from you were posted
> there and accepted there previously as a non-subscriber and added to
> the whitelist.
> 
> Did you possibly post from a different address previously?

No.

>  Was it
> different form the one you just now used to post to the list?

Slightly. I've attached the automatic replies. The first one
also contains the original message.


> I am not really sure what to suggest might be the problem.  But it
> would seem to be a problem between your site and the gnu.org site
> where the messages never arrived at gnu.org.  If you could look in
> your MTA logs to see what the disposition of that message was it would
> probably point to a problem there.

What is an MTA log and where can I find it?


Regards,
Andreas BüningReturn-Path: <[EMAIL PROTECTED]>
X-Original-To: [EMAIL PROTECTED]
Received: from localhost (mail-in-07.arcor-online.net [151.189.21.47])
by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id AF6B7CB43D
for <[EMAIL PROTECTED]>; Sun,  7 May 2006 18:34:08 +0200 (CEST)
Received: from mail-in-07.arcor-online.net ([127.0.0.1])
 by localhost (mail-in-07 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 27101-01-33 for <[EMAIL PROTECTED]>;
 Sun,  7 May 2006 18:34:08 +0200 (CEST)
Received: from lists.gnu.org (lists.gnu.org [199.232.76.165])
by mail-in-07.arcor-online.net (Postfix) with ESMTP id 1D507164062
for <[EMAIL PROTECTED]>; Sun,  7 May 2006 18:34:08 +0200 (CEST)
Received: from localhost ([127.0.0.1] helo=lists.gnu.org)
by lists.gnu.org with esmtp (Exim 4.43)
id 1FcmCs-00033x-Ex
for [EMAIL PROTECTED]; Sun, 07 May 2006 12:34:06 -0400
Subject: The results of your email commands
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===2066722360=="
Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 07 May 2006 12:34:02 -0400
Precedence: bulk
X-BeenThere: automake-patches@gnu.org
X-Mailman-Version: 2.1.5
List-Id: Patches for Automake 
X-List-Administrivia: yes
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-Virus-Scanned: amavisd-new at arcor.de
X-DCC-servers-Metrics: mail-in-01-z2 1049; Body=1 Fuz1=1 Fuz2=1
X-Arcor-Antispam:  SPF_PASS_AT_FORMER_RECEIVED
X-Spamcount: -1
X-Spamsensitivity: 12
X-Mozilla-Status: 8001
X-Mozilla-Status2: 
X-UIDL: UID23111-1075230453

--===2066722360==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

The results of your email command are provided below. Attached is your
original message.


- Unprocessed:
I tried to use aclocal 1.9.6 on OS/2 and encountered the following
problem: If using a drive letter for the installation path the $_
variable (see below) will contain something like
"c:/usr/share/aclocal-1.9/init.m4:AC_INIT_AUTOMAKE.". This will
obviously break when the split function is called because $file will
be initializes to "c" and $macro to "/usr/share/aclocal-1.9/init.m4".
Finally, init.m4 will not be considered as a file needed for aclocal.m4,
and won't be included there. This means, AC_INIT_AUTOMAKE and all other
standard macros won't be in aclocal.m4 and any call of automake will
fail.
I replaced split(/:/) by split (/(?<=3D\w\w):/) which will ignore the
first
colon if there aren't at least two characters before the colon. Maybe
you'll find a better solution since I'm not a perl expert.

--- old/automake-1.9.6/aclocal.in   Sat Jul  9 11:28:44 2005
+++ gnu/automake-1.9.6/aclocal.in   Sun May  7 00:51:24 2006
@@ -423,7 +423,8 @@
   while ($_ =3D $tracefh->getlin

aclocal 1.9.6 and drive letters

2006-05-26 Thread Andreas Büning
Hello!

Some weeks ago I sent a mail to the automake-patches mailing list
but it never appeared there. Then I tried the bug-automake
mailing list. I checked the mailing list archives on lists.gnu.org
my posting never appeared. So I'm trying again on the automake
mailing list:


I tried to use aclocal 1.9.6 on OS/2 and encountered the following
problem: If using a drive letter for the installation path the $_
variable (see below) will contain something like
"c:/usr/share/aclocal-1.9/init.m4:AC_INIT_AUTOMAKE.". This will
obviously break when the split function is called because $file will
be initializes to "c" and $macro to "/usr/share/aclocal-1.9/init.m4".
Finally, init.m4 will not be considered as a file needed for aclocal.m4,
and won't be included there. This means, AC_INIT_AUTOMAKE and all other
standard macros won't be in aclocal.m4 and any call of automake will
fail.

I replaced split(/:/) by split (/(?<=\w\w):/) which will ignore the
first colon if there aren't at least two characters before the colon.
Maybe you'll find a better solution since I'm not a perl expert.


Regards,

Andreas Büning--- old/automake-1.9.6/aclocal.in   Sat Jul  9 11:28:44 2005
+++ gnu/automake-1.9.6/aclocal.in   Sun May  7 00:51:24 2006
@@ -423,7 +423,8 @@
   while ($_ = $tracefh->getline)
 {
   chomp;
-  my ($file, $macro, $arg1) = split (/:/);
+  # make sure that the filename does not start with a drive letter like 
x:/usr/...
+  my ($file, $macro, $arg1) = split (/(?<=\w\w):/);
 
   $traced{$macro} = 1 if $macro_seen{$macro};
 


Re: make distcheck not finding custom code generation script

2006-05-13 Thread Andreas Ntaflos
On Saturday 13 May 2006 10:23, Ralf Wildenhues wrote:
> The concept that is probably new to you is when source tree and build
> tree are not the same.  You can achieve that yourself (without
> distcheck) by something like this:
>   mkdir build
>   cd build
>   ../source-tree/configure [OPTIONS]
>   make

Ralf, 

thank you too very, very much for another great explanation! That 
concept was indeed new to me (autotools newbie), but now I understand  
well enough I think, which I am very happy about :)

> BTW, what a well-written bug report!

Why, thank you :) It got me at least two great answers so it was 
definately worth writing it.

Thanks, once again!

Andreas
-- 
Andreas "daff" Ntaflos 
daff AT dword DOT org
Vienna, Austria 

GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4
GPG Public Key ID:  090CA9B4
GPG Public Key: http://daffit.meownz.info/publickey/andreas_ntaflos.asc




Re: make distcheck not finding custom code generation script

2006-05-13 Thread Andreas Ntaflos
On Saturday 13 May 2006 10:16, Andreas Ntaflos wrote:
> It seems you replied off-list? 

Nevermind, I didn't realize the automake list was apparently CC'd. Need 
some sleep and better procmail rules.
-- 
Andreas "daff" Ntaflos 
daff AT dword DOT org
Vienna, Austria 

GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4
GPG Public Key ID:  090CA9B4
GPG Public Key: http://daffit.meownz.info/publickey/andreas_ntaflos.asc




Re: make distcheck not finding custom code generation script

2006-05-13 Thread Andreas Ntaflos
On Saturday 13 May 2006 09:54, Brian Dessent wrote:
> So the answer to your question is that you shouldn't assume that you
> are in the source tree when referring to files.  Try having your
> macro expand the path as "$(srcdir)/tools/wrapper.sh" instead of
> "../tools/wrapper.sh".  I'm not entirely sure of the correct quoting
> here, but I'm pretty sure you want it to expand as $(srcdir) in the
> final generated Makefile rule, so this might involve quoting the ('s
> and )'s in m4, I don't know.

Brian, 

I can't thank you enough for taking the time to read that long post of 
mine /and/ reply with such a detailed and well-written explanation!
And of course you are correct, having the m4 macro expand the variable 
to $(srcdir)/tools/wrapper.sh (and, along the same lines, rewriting the 
build rule to refer to $(srcdir)/foo.ice) solved that problem just 
fine!

About the quoting in the m4 macro: 

ac_foo2cpp="\$(srcdir)/tools/wrapper.sh ${ac_foo2cpp}"

was apparently the right way to do this.

It seems you replied off-list? Would you consider posting to the list 
what you wrote? Your explanation is definately worth archiving and I 
know for a fact that many of my fellow students will be having similar 
problems pretty soon.

If you don't want to I could forward your message or quote it in a 
follow-up or whatever.

Again, thank you very much! You spared me a lot of further trouble :)

Andreas
-- 
Andreas "daff" Ntaflos 
daff AT dword DOT org
Vienna, Austria 

GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4
GPG Public Key ID:  090CA9B4
GPG Public Key: http://daffit.meownz.info/publickey/andreas_ntaflos.asc




make distcheck not finding custom code generation script

2006-05-12 Thread Andreas Ntaflos
Hello list, 

this is my first post here, and it is regarding `make distcheck'. What I 
have to do is a bit tricky to explain but hopefully I can make myself 
clear enough to get some input from more experienced automake users 
than me (I am basically a newbie). I would really appreciate it.

Background:

To build successfully, my package needs two files (foo.cc and foo.hh) 
that are generated during build time from another file (foo.ice) using 
a special program, let's call it `foo2cpp'. This program's path is 
machine/installation dependent and is determined during configure time 
and set correctly by the m4 macro that checks for it. This m4 makro 
creates a Makefile variable $(ICE_FOO2CPP) which looks like this: 
`../tools/wrapper.sh /correct/path/to/foo2cpp'.

You see, in the topmost directory of my package there is a directory 
`tools' which contains a `wrapper.sh' script. This is needed to set 
various paths (like LD_LIBRARY_PATH) in order for foo2cpp to run 
correctly on all test machines. So to translate foo.ice to foo.cc and 
foo.hh I need to run (in my $(topdir)/src subdirectory) 

../tools/wrapper.sh /path/to/foo2cpp foo.ice

In src/Makefile.am there is a target that does just that:

foo.cc foo.hh: foo.ice
$(ICE_FOO2CPP) foo.ice

It does so very nicely. Remember $(ICE_FOO2CPP) is set during configure 
after the m4 macro checked for it.

These generated files are of course not part of the distribution but are 
nodist_foo_SOURCES and set in BUILT_SOURCES, accoring to the automake 
info section on built sources. This part is working fine.

I of course included the tools/wrapper.sh script in EXTRA_DIST in the 
top level Makefile.am. I am also including foo.ice in EXTRA_DIST of 
src/Makefile.am.

What works:

configuring and making the package is no problem at all, everything is 
set correctly and compiling fine. Making a distribution with `make 
dist' and then unpacking and building this distribution is also no 
problem.

What doesn't work:

The problem is that `make distcheck' fails right at the beginning of the 
build process, after configuring. It complains about not finding the 
tools/wrapper.sh script:

make[1]: Entering directory `/path/to/foo_project/foo-1.0/_build'
make  all-recursive
make[2]: Entering directory `/path/to/foo_project/foo-1.0/_build'
Making all in src
make[3]: Entering directory `/path/to/foo_project/foo-1.0/_build/src'
../tools/wrapper.sh /usr/bin/foo2cpp foo.ice
make[3]: ../tools/wrapper.sh: Command not found

Which is correct, there is no wrapper.sh script from where make 
distcheck is looking (i.e. from 
inside /path/to/foo_project/foo-1.0/_build/src). Also there are no 
other files in foo-1.0/_build/src, so even if the wrapper.sh script 
could be found it would choke on not finding foo.ice.

The wrapper.sh script is in foo-1.0/tools where it belongs and where it 
is found fine when building a readily distributed package of foo (make 
dist). 

Question:

The question is: what do I have to do to satisfy make distcheck about 
the location of the script? Or am I doing something wrong here? Did I 
forget to set a special variable that lets make distcheck know that 
there are files that need to be built from other files before being 
able to `make' anyting? Do I have to define the path to the script 
otherwise? Please note that I encountered the same problem when the 
wrapper.sh script was placed directly in the src/ subdirectory (and 
distributed correctly). 

Or did I hit a limitation of automake? Is it not able to deal with such 
things? 

To reiterate: building a `make dist'ed package works fine and so does 
building the package in it's root directory. It's just make distcheck 
that fails.

Sorry for this much too long post, I hope I explained my problem well 
enough for somebody (who was brave enough to read it all) to be able to 
help me.

Any help is appreciated! Especially RTFM answers that contain links to 
TFM and the relevant sections :)

Thanks in advance!

Andreas
-- 
Andreas "daff" Ntaflos 
daff AT dword DOT org
Vienna, Austria 

GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4
GPG Public Key ID:  090CA9B4
GPG Public Key: http://daffit.meownz.info/publickey/andreas_ntaflos.asc




Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Andreas Schwab
Keith Marshall <[EMAIL PROTECTED]> writes:

> Let me turn that around, and ask if you can provide any documentary 
> evidence, other than anecdotal, to suggest that this use of semicolons 
> *should* be supported? SUSv3 *expressly* demands that sed directives be 
> separated by newlines:
> http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html

"The command can be preceded by s and/or semicolons. The function
can be preceded by s. These optional characters shall have no
effect."

"Command verbs other than {, a, b, c, i, r, t, w, :, and # can be followed
by a semicolon, optional s, and another command verb."

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Andreas Schwab
Keith Marshall <[EMAIL PROTECTED]> writes:

> On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote:
>> On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote:
>> > here's a patch that I think does more or less what Bruno's patch
>> > intends to do, against current CVS.
>>
>> I worked on the same issue.  We both use the same pattern
>> `sed -n '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...`
>
> I'd like, if I may, to sound a note of caution concerning this sed 
> command syntax: the use of semicolons as command separators in the sed 
> script is an implementation dependent extension, which is not portable.  
> On some platforms, the test using this sed syntax *will* fail, not 
> because the feature you are testing is unsupported, but because the test 
> itself is invalid.
>
> In November 2005, Robert Goulding posted these bug reports on 
> groff@gnu.org:
> http://lists.gnu.org/archive/html/groff/2005-11/msg4.html
> http://lists.gnu.org/archive/html/groff/2005-11/msg00074.html
>
> It turns out that Robert was having a problem building CVS groff,
> which requires texinfo >= 4.8 to compile the info files, under Mac OS X, 
> and configure was saying his texinfo was too old, in spite of him having 
> explicitly just installed texinfo-4.8.  The actual problem was that the 
> configure test employed a sed command with this same semicolon usage,
> and was not behaving as expected -- the test failed because *it* was 
> invalid, *not* because the detected texinfo was too old!

Is there any evidence that there exists a sed implementation that does not
support the semicolon as command separator?  Note that the thread you
quote above is _not_ about semicolons being unsupported, but rather about
missing ones.  Autoconf is using semicolons in sed expressions already for
many years (eg in the AC_OUTPUT_FILES macro).

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: best aclocal include practice wanted

2006-03-04 Thread Andreas Schwab
Thomas Porschberg <[EMAIL PROTECTED]> writes:

> what is the recommended way to include project-written m4 macros ?

Many projects use a directory named m4, but there is no common convention.

> I include the macros in /config/m4
> and call in autogen.sh "aclocal -I config/m4"
>
> The config directory itself is configured in configure.ac
> with AC_CONFIG_AUX_DIR(config).

This macro is unrelated to the placement of the input files for aclocal.

> Is there something wrong with this approach ?

No.

> What could be done better ?
> How should autoreconf find the m4-macros in such a case ?

Add this line to the toplevel Makefile.am:

ACLOCAL_AMFLAGS = -I config/m4

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: build paths and generated sources

2006-01-29 Thread Andreas Schwab
Thomas Porschberg <[EMAIL PROTECTED]> writes:

> %.cpp %.h: %.ui
> @UIC@ -o $(<:%.ui=%.h) $<
> @UIC@ -i $(<:%.ui=%.h) -o $(<:%.ui=%.cpp) $<

You should not use $< for constructing targets, only $@ will contain the
right name to create.  IIUC the commands are creating the each of two
targets separately, thus you should use two separate rules:

%.h: %.ui
@UIC@ -o $@ $<
%.cpp: %.h %.ui
@UIC@ -o $@ -i $^

This make sure that each comand argument has the correct directory part.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Alternative compiling for debug/optimized code?

2005-12-08 Thread Andreas Schwab
"Daniel Kraft" <[EMAIL PROTECTED]> writes:

> Using automake the default compiler flags seem to be -g -O2; but most of the
> time I don't need debug code

You'll need it most when you don't have it.

> so I want to disable that -g - option.

./configure CFLAGS=-O2

> And it is possible to do something similiar to the alternative compiling
> described above - i.e. to have a simple way for switching opt/debug mode, 
> maybe
> without having to reconfigure?

make CFLAGS=-O2

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: shared library from smaller pieces

2005-12-04 Thread Andreas Schwab
Vlad Skvortsov <[EMAIL PROTECTED]> writes:

> When I use something like this:
>
> lib_LT_LIBRARIES = libbig.la
> libbig_la_LIBADD = .../libaaa.la .../li.la .../libccc.la
>
> I end up with the shared library that contains _references_ to _shared_ 
> libraries aaa, bbb and ccc. But I just want their contents to be packed 
> inside.
>
> How can I achieve that?

Make the small pieces convenience libraries, by using noinst_LTLIBRARIES.
*Note (automake)Libtool Convenience Libraries::.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Moving from manual Makefiles to Automake

2005-11-09 Thread Andreas Schwab
Paulo Jorge Matos <[EMAIL PROTECTED]> writes:

> if g++ -DHAVE_CONFIG_H -I. -I. -I..-I./include -ansi -std=c++98
> -pedantic -Wall -DBUILDDATE=`date +'%Y-%b-%d %R'` -g -O2 -MT
  ^
You need to quote the output of the command substitution since it contains
a space.

  -DBUILDDATE="`date +'%Y-%b-%d %R'`"

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: AM_FCFLAGS not working as I expect...

2005-11-05 Thread Andreas Schwab
Ed Hartnett <[EMAIL PROTECTED]> writes:

> What am I missing here? I define the following in my Makefile.am:
>
> # Point the fortran compiler to current directory.
> AM_FFLAGS = -I$(srcdir)
>
> But no matter what I do, that -I. never appears when the compile
> happens:
>
>  f95 -g -O2 -ff2c -c typeSizes.f90  -fPIC -o .libs/typeSizes.o

FFLAGS is only used for Fortran 77 compilations.  For Fortran 9x
compilations FCFLAGS is used.  See Fortran 77 Support and Fortran 9x
Support in the automake manual.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Defining Macros With Literal Values

2005-10-26 Thread Andreas Schwab
Eric Lemings <[EMAIL PROTECTED]> writes:

> Greetings,
>
> I have a tricky little problem I was hoping someone could
> help me with.  I am trying to write an Autotools macro that
> extracts the value of a macro from a system header file
> and defines another preprocessor macro with the same value.

You can use AC_DEFINE_UNQUOTED to define a macro to the result of a shell
substitution.  You can easily extract the value from the output of the
preprocessor.  Don't use the output of a compiled program because that
would make cross-compiling impossible.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: configure can not determin 'HAVE_LIMITS'

2005-10-26 Thread Andreas Schwab
Ralf Corsepius <[EMAIL PROTECTED]> writes:

> limits.h is a POSIX header. On linux it is supplied by GCC.
>
> So if you want to check for "limits", you should use
> AC_CHECK_HEADERS([limits])
>
> If this fails, something else is broken and you will have to
> investigate. It could be a bug inside of "limits", it could be problem
> elsewhere inside of your configure script, or could be a problem with
> your include paths.

Note that  is a C++ header.  By default, configure scripts don't
use the C++ compiler when checking for headers.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Avoiding installation

2005-09-03 Thread Andreas Schwab
John Kodis <[EMAIL PROTECTED]> writes:

> I'd like a program to be built when I type "make", but not have it
> installed when I type "make install".  Is there a provision for this?

Use the noinst prefix, like noinst_PROGRAMS.  See (automake)Uniform.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: I can't get xxx_AR to work

2005-07-30 Thread Andreas Buening
Patrik Jonsson wrote:

> I'm trying to convert my little project to autotools, and I'm running
> into the problem that under AIX, to make a 64-bit library, you need to
> pass -X64 as an option to ar. I've tried setting libmcrx_a_AR =
> something, ARFLAGS =something and AR =something in the Makefile.am, but
> no matter how I do this, the Makefile always comes out having:

I had a similar problem and played around with it long time ago.
The simplest (though inconvenient) way is to call 'make AR="ar -X64"'
every time you need it.
Otherwise, you could write some shell code in configure.ac to determine
AR or ARFLAGS and to set them with AC_SUBST. I think this should work.


Andreas




Re: Specifying AM_CPPFLAGS from within configure.ac

2005-06-06 Thread Andreas Schwab
Jirka Hanika <[EMAIL PROTECTED]> writes:

> For example I'll try to upgrade the "unused variable" warning avoidance
> code to something like
>
> if (((int)argv) * ((int)argv) < 0 || argc < 0) printf("");

conftest.c: In function ‘main’:
conftest.c:5: warning: cast from pointer to integer of different size
conftest.c:5: warning: cast from pointer to integer of different size
conftest.c:5: warning: zero-length printf format string

conftest.cc: In function ‘int main(int, char**)’:
conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
conftest.cc:5: warning: zero-length printf format string

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: .DELETE_ON_ERROR ?

2005-05-10 Thread Andreas Schwab
Stepan Kasal <[EMAIL PROTECTED]> writes:

> Hello,
>   I've just stumbled over this problem:
> Makefile.am contains:
>
> foo.h: foo.x
>   $(GENERATOR) foo.x >foo.h
>
> But the GENERATOR command failed and I have empty foo.h.

Use a temporary file and rename that afterwards.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: F90 vs. F77

2005-04-19 Thread Andreas Schwab
Scott Kruger <[EMAIL PROTECTED]> writes:

> I am using automake version 1.8.2

This is quite old, the latest version is 1.9.5.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: 5.9 The Future of `aclocal'

2005-01-30 Thread Andreas Schwab
Bruce Korb <[EMAIL PROTECTED]> writes:

> In fiddling with sharutils, I discovered that it is  too early to encourage
> the dropping of bootstrap scripts just yet.  "autoreconf" does not  provide
> a way of convincing automake to run with the options, "--gnu" and 
> "--add-missing".

Sure it does.  "--gnu" comes from AUTOMAKE_OPTIONS in Makefile.am or from
AM_INIT_AUTOMAKE, and "--add-missing" is added with "--install".

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: CCing list replies (was: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?)

2005-01-16 Thread Andreas Schwab
Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> This is not addressed at me, but I also had to learn the hard way
> that
> - some gnu.org lists but not all automatically exclude subscribers if
>   they are listed in To: or Cc:.

This is customizable, see the mailman options page.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: troubles with conditional install using automake

2004-12-01 Thread Andreas Schwab
Stepan Kasal <[EMAIL PROTECTED]> writes:

> Hi,
>
> while I am not able to address your main problem, I'd like to address one
> misunderstanding of the make language:
>
> On Wed, Dec 01, 2004 at 03:29:10PM +0100, Guillaume Rousse wrote:
>> initrd_SCRIPTS is defined to $(INITRD) at the beginning of the Makefile, 
>> while INITRD is defined at the end of the Makefile, with other 
>> conditional variables, and thus appears empty when it is evaluated.
>
> No, make doesn't work this way; consider the makefile:
>
> A = $(BB)
>
> e:
> echo $(A)
>
> BB=x
>
>
> Then ``make'' runs ``echo x''

But when $(A) appears on the dependency list of e, for example, it will be
expanded already while the makefile is being read in.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Error because README is missing

2004-11-29 Thread Andreas Schwab
"Paul D. Smith" <[EMAIL PROTECTED]> writes:

> However, I actually had a second error that I didn't mention because I
> figured it would be the same problem... but it's not.
>
> The second error is this:
>
>   $ automake --add-missing --no-force
>   configure.in:398: required file `build.sh.in' not found
>
> This file is being created with this in my configure.in file:
>
>   if test -f $srcdir/build.sh.in; then
> AC_CONFIG_FILES(build.sh)
>   fi

AC_CONFIG_FILES is a declaration-like macro, you can't execute it
conditionallyon the shell level.  If you want to make it conditional on
the existence of the input file you need to do that on the m4 level.

Untested code ahead.

m4_syscmd([test -f build.sh.in])dnl
m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)])

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Disabling optimization

2004-11-18 Thread Andreas Schwab
"Thomas 'Tom' R. Treadway III" <[EMAIL PROTECTED]> writes:

> CXXFLAGS="`echo $CXXFLAGS | sed -e 's|-O2||'`"

This assumes that CXXFLAGS does not contain "-frob-O2any".

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: Disabling optimization

2004-11-18 Thread Andreas Schwab
Stepan Kasal <[EMAIL PROTECTED]> writes:

> out of curiosity, what would be wrong with the following?
>
> if test -n "${CXXFLAGS}"; then
>   CXXFLAGS="-g"
> fi
> AC_PROG_CXX

I think you got it backwards.  This makes it impossible to override
CXXFLAGS.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




  1   2   >