Re: Multiple definition of VERSION, PACKAGE and so on
On Tue, 23 Mar 2004, Guido Draheim wrote: > > What I mean by "interact" is that one package uses on another one :-) > > I can give you an example. I have a package pack1 which I have encapsulated > > in another one, pack2 (I mean that I have a subdirectory pack2 in pack1 > > and that configure.ac of pack2 has a AC_CONFIG_SUBDIRS(pack1) command). > > I have choosen this architecture since pack2 (plasma simulator) builds on > > top of pack1 (pde solver) and pack1 could be used on its own or for other > > projects. > > > > Until recently, I didn't use the command AC_CONFIG_HEADERS and I didn't > > have any problem since the macros definition -DPACKAGE -DVERSION were > > option commands and put just once per compiler command. > > > > Now I wanted to start using AC_CONFIG_HEADERS because I have too many > > defs, so I have just a AC_CONFIG_HEADERS([pack1-config.h]) > > and AC_CONFIG_HEADERS([pack2-config.h]) for each package. > > The pack1-config.h is included only if HAVE_CONFIG_H is defined and is > > included in my definition file for the package (C++ typedefs for template > > arrays (double/float), constant defs, dimensionnality of the problem, MPI > > use, FFTW use, HDF use, etc...). Each class declaration and definition > > needs this file. The same is done in pack2 but some classes of pack2 uses > > public methods of pack1 classes. Therefore in some classes definition of > > pack2 I have to include the class declaration of some peculiar classes from > > pack1. The result is that the pack1-config.h and pack2-config.h are both included. > > > > Now I don't really see how I can avoid that. But you may have suggestions? > > > > As said before - it is TOTAL ERROR to include config.h (here: pack1-config.h) > into header files made publically available to outside projects (here: pack2). > I would definitely like to hear how do you handle the following solution if you mean this is TOTAL ERROR to include config.h into header files that are made publically available to outside projects. As far as now I have a pack1-defs.h header file containing definitions like: #if defined(HAVE_CONFIG_H) #include #endif #if defined(FLOAT_FIELD) typedef float pack1Real; #elif defined(DOUBLE_FIELD) typedef double pack1Real; #else #error macro FLOAT_FIELD or DOUBLE_FIELD must be defined #endif typedef blitz::Array Array1dr; typedef blitz::Array Array2dr; typedef blitz::Array Array3dr; typedef blitz::Array Field; I need to make this file publically available to outside projects if I don't want to redefine type Field for example. But to do so I have to include pack1-config.h as well since definition FLOAT_FIELD or DOUBLE_FIELD needs to be defined. That's the way we handle definitions in the Blitz++ project as well so if you have a better solution let me know! > as a solution, instead of current usage, modify pack1/configure.ac to use >AC_CONFIG_HEADER >AX_PREFIX_CONFIG_HEADER([pack1-config.h]) > This does not work with autoconf-2.59/automake-1.8.3. % autoreconf -vif autoreconf: Entering directory `mudfas' autoreconf: running: libtoolize --copy --force Putting files in AC_CONFIG_AUX_DIR, `config'. autoreconf: running: /usr/local/gnu/bin/autoconf --force autoreconf: running: /usr/local/gnu/bin/autoheader --force autoheader: error: AC_CONFIG_HEADERS not found in configure.ac autoreconf: running: automake --add-missing --copy --force-missing configure.ac:10: not enough arguments for AC_CONFIG_HEADERS Still a new configure is generated. But then when running configure ./configure: line 1580: syntax error near unexpected token `src/mudfas-config.h' ./configure: line 1580: `AX_PREFIX_CONFIG_HEADER(src/mudfas-config.h)' It looks like AC_CONFIG_HEADER is enough (whithout S). So you don't need to have the whole keyword but a long enough one to be unambiguous? I have another remark. Is the use of AC_CONFIG_HEADER expected to have the same behaviour as passing argument on line? (Because it is not necessary the same behaviour as said in an earlier email) Sincerely, Patrick
Re: Multiple definition of VERSION, PACKAGE and so on
On Mon, 22 Mar 2004, Guido Draheim wrote: > > > Patrick Guio wrote: > > > > Dear all, > > This is not really a bug but I wonder if you have any remedy to the > > following problem. If you use autoconf/automake for several packages > > which interact with each other and for each package you generate a > ^^ > > configuration file config.h you migh end up with redefinition warning > > message if config.h's are read "together". >^^ > > > > ... warning: "PACKAGE_VERSION" redefined > > ... warning: this is the location of the previous definition > > > > ... warning: "VERSION" redefined > > ... warning: this is the location of the previous definition > > > > My concern is how to avoid this? Shouldn't these macro defintion be unique > > for each package? Should there be a protection mechanism? > > > > *How* do you let them "interact with each other"? > *Why* are config.h's read together? > What I mean by "interact" is that one package uses on another one :-) I can give you an example. I have a package pack1 which I have encapsulated in another one, pack2 (I mean that I have a subdirectory pack2 in pack1 and that configure.ac of pack2 has a AC_CONFIG_SUBDIRS(pack1) command). I have choosen this architecture since pack2 (plasma simulator) builds on top of pack1 (pde solver) and pack1 could be used on its own or for other projects. Until recently, I didn't use the command AC_CONFIG_HEADERS and I didn't have any problem since the macros definition -DPACKAGE -DVERSION were option commands and put just once per compiler command. Now I wanted to start using AC_CONFIG_HEADERS because I have too many defs, so I have just a AC_CONFIG_HEADERS([pack1-config.h]) and AC_CONFIG_HEADERS([pack2-config.h]) for each package. The pack1-config.h is included only if HAVE_CONFIG_H is defined and is included in my definition file for the package (C++ typedefs for template arrays (double/float), constant defs, dimensionnality of the problem, MPI use, FFTW use, HDF use, etc...). Each class declaration and definition needs this file. The same is done in pack2 but some classes of pack2 uses public methods of pack1 classes. Therefore in some classes definition of pack2 I have to include the class declaration of some peculiar classes from pack1. The result is that the pack1-config.h and pack2-config.h are both included. Now I don't really see how I can avoid that. But you may have suggestions? Sincerely Patrick > To answer right away on a frequently asked question: do not install > config.h and do not #include it in public headers of a (sub)project. > Use ax_prefix_config_h to avoid problems with ac_define's > occuring in two autoconfigured header files instead. > > btw, -> autoconf people, may be we should move the prefix'config > macro to main autoconf and/or reference it in main documentation? >
_TEXINFOS question
Dear all, I am using the _TEXINFOS variables in a Makefile.am to build the documentation. I would like these to be built on request with a `doc' target for example and not with the default 'all' or 'all-am'. Is there a way to do that? Sincerely, Patrick
autoreconf --flavor ?
Dear all, I am using currently autoconf 2.57 and automake 1.7.2. I find it annoying not to be able to use te nice tool autoreconf without that all the following files NEWS, README, AUTHORS and ChangeLog should be present in the current directory. automake has the possibility to disable that feature with the --foreign option. Why not allow autoreconf to take in options for the other tools? Sincerely, Patrick
-rm -f core.$pid
Dear all,
In recent Linux version, core files generated are called after process id
with the syntax
core.$pid
which can be matched I think
for csh-like shells with core.{[1-9]*}
for sh-like shells with core.[0-9]*
That might be nice to remove those as well?
Cheers, Patrick
Configure tool/cvs repository trouble
Dear all, I have been using the configure tool for a while together with my project managed with cvs. Until recently I was running autoconf 2.49c automake 1.4a and libtool 1.3c and I had no problem when modifying any of the configuration file configure.in or any Makefile.am, rerun aclocal/automake... committing my changes, update on another and rerun configure. Now recently I moved to autoconf 2.53, automake 1.6.1, libtool 1.4.2 and I systematically run into time stamp trouble whe doing an update on another machine after having rebuild the system. I can run the configure but when running make I get WARNING: `aclocal-1.6' is missing on your system. You should only need it if you modified `acinclude.m4' or `configure.in'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. WARNING: `automake-1.6' is missing on your system. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.in'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. If I just "touch configure" then everything is running ok again. I am not sure which of the package is generating this trouble nut is there any policy/strategy of using configuration tool together with a cvs repository? Sincerely, Patrick
Bug in conditional library building
Dear all, I had the following Makefile.am running generating a proper Makefile.in with automake 1.4a and libtool 1.3c UTILSRC = parser.cpp integrate.cpp MUDSRC = init.cpp linear_solver.cpp mudfas.cpp nonlinear_solver.cpp \ poisson_boltzmann.cpp poisson.cpp prolon.cpp restrict.cpp lib_LTLIBRARIES = libmudfas2d.la libmudfas3d.la libutilities.la libmudfas2d_la_SOURCES = $(MUDSRC) libmudfas2d_la_CXXFLAGS = -DDIM=2 libmudfas2d_la_LDFLAGS = -version-info 0:0:0 libmudfas3d_la_SOURCES = $(MUDSRC) libmudfas3d_la_CXXFLAGS = -DDIM=3 libmudfas3d_la_LDFLAGS = -version-info 0:0:0 libutilities_la_SOURCES = $(UTILSRC) libutilities_la_CXXFLAGS = libutilities_la_LDFLAGS = -version-info 0:0:0 which generated the following piece of Makefile.in libmudfas2d_la_LIBADD = am_libmudfas2d_la_OBJECTS = libmudfas2d_la-init.lo \ libmudfas2d_la-linear_solver.lo libmudfas2d_la-mudfas.lo \ libmudfas2d_la-nonlinear_solver.lo libmudfas2d_la-poisson_boltzmann.lo \ libmudfas2d_la-poisson.lo libmudfas2d_la-prolon.lo \ libmudfas2d_la-restrict.lo libmudfas2d_la_OBJECTS = $(am_libmudfas2d_la_OBJECTS) libmudfas3d_la_LIBADD = am_libmudfas3d_la_OBJECTS = libmudfas3d_la-init.lo \ libmudfas3d_la-linear_solver.lo libmudfas3d_la-mudfas.lo \ libmudfas3d_la-nonlinear_solver.lo libmudfas3d_la-poisson_boltzmann.lo \ libmudfas3d_la-poisson.lo libmudfas3d_la-prolon.lo \ libmudfas3d_la-restrict.lo libmudfas3d_la_OBJECTS = $(am_libmudfas3d_la_OBJECTS) libutilities_la_LIBADD = am_libutilities_la_OBJECTS = libutilities_la-parser.lo \ libutilities_la-integrate.lo libutilities_la_OBJECTS = $(am_libutilities_la_OBJECTS) Now I moved to the last official versions automake 1.6.1 and libtool 1.4.2 and I have the very unpleasant result that the generated Makefile.in does not work any longer. I get instead of what is below the following code in the Makefile.in libmudfas2d_la_LIBADD = am__objects_1 = libmudfas2d_la-init.lo libmudfas2d_la-linear_solver.lo \ libmudfas2d_la-mudfas.lo libmudfas2d_la-nonlinear_solver.lo \ libmudfas2d_la-poisson_boltzmann.lo libmudfas2d_la-poisson.lo \ libmudfas2d_la-prolon.lo libmudfas2d_la-restrict.lo am_libmudfas2d_la_OBJECTS = $(am__objects_1) libmudfas2d_la_OBJECTS = $(am_libmudfas2d_la_OBJECTS) libmudfas3d_la_LIBADD = am_libmudfas3d_la_OBJECTS = $(am__objects_1) libmudfas3d_la_OBJECTS = $(am_libmudfas3d_la_OBJECTS) libutilities_la_LIBADD = am__objects_2 = libutilities_la-parser.lo libutilities_la-integrate.lo am_libutilities_la_OBJECTS = $(am__objects_2) libutilities_la_OBJECTS = $(am_libutilities_la_OBJECTS) which results in that the mudfas3d library with the define DIM=3 is not built any longer. Any idea of what is wrong ? Sincerely, Patrick == Patrick Guio Institute of Physics, University of Oslo P.O. box 1048, Blindern, N-0316 Oslo Tel : (+47) 22 84 40 60 - Fax : (+47) 22 85 56 71 E-mail : [EMAIL PROTECTED] URL : http://folk.uio.no/~patricg
Re: Install question
On Thu, 24 Jan 2002, Alexandre Duret-Lutz wrote: > >>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > > [...] > > adl> EXTRA_PROGRAMS = ex1 ex2 > adl> ex1_SOURCES = ex1.cpp > adl> ex2_SOURCES = ex2.cpp > adl> check-examples: $(EXTRA_PROGRAMS) > > Or even: > > check_PROGRAMS = ex1 ex2 > ex1_SOURCES = ex1.cpp > ex2_SOURCES = ex2.cpp > > This will compile ex1 and ex2 only for `make check'. > -- > Alexandre Duret-Lutz > > Hei Alexandre, What happens with make install and make dist ? Sincerely, Patrick
Install question
Dear all, I have a hierarchy of directories from the $(top_srcdir) like $(top_srcdir)/includes1, $(top_srcdir)/includes1/sub1, $(top_srcdir)/includes1/sub2, $(top_srcdir)/includes2 which contains c++ includes which I want to install in $(includedir) like $(includedir)/includes1, $(includedir)/includes1/sub1, $(includedir)/includes1/sub2, $(includedir)/includes2 Which variableshall I use in each Makefile.am? nobase_include_HEADERS ? include_HEADERS ? or something else? Sincerely, Patrick
Re: Question about AC_CONFIG_FILES
On 9 Dec 2001, Ralf Corsepius wrote:
Thank you for your answer, I had also found out that I could use the shell
syntax AC_CONFIG_FILES([class1.cpp:main.cpp.in])
But the problem is now how to instantiate the variable class_name with
different values. I tried
AC_SUBST(class_name,"class1")
AC_CONFIG_FILES([class1.cpp:main.cpp.in])
AC_SUBST(class_name,"class2")
AC_CONFIG_FILES([class2.cpp:main.cpp.in])
Here both class2.cpp and class1.cpp will be instantiated with the same
value "class2" (i.e. the last AC_SUBST for class_name in the
configure.in file). Is there a way to solve this problem?
Sincerely
Patrick
> Am Sam, 2001-12-08 um 20.42 schrieb Patrick Guio:
> >
> > Dear all,
> > I have a c++ "template" main program. I mean by this that the skeleton of
> > the program is the same but different class can be used. What I would like
> > to do is from the main.cpp.in template program where a variable class_name
> > is used for example as
> > int main
> > {
> > @class_name@ simulator;
> > ...
> > }
> > to be able to replace the @class_name@ using AC_CONFIG_FILES.
> > I was thinking to write in the configure.in something like
> > class_name="class1"
> > AC_CONFIG_FILES(class1.cpp)
> > class_name="class2"
> > AC_CONFIG_FILES(class2.cpp)
> > and so on...
> > The problem is that AC_CONFIG_FILES will look for a class1.cpp.in,
> > class2.cpp.in while I would like it to always look for the default
> > main.cpp.in.
> > Any idea of how to do that?
> Have you tried something similar to this?
>
> AC_CONFIG_FILES([class1.cpp:main:cpp.in])
>
Question about AC_CONFIG_FILES
Dear all,
I have a c++ "template" main program. I mean by this that the skeleton of
the program is the same but different class can be used. What I would like
to do is from the main.cpp.in template program where a variable class_name
is used for example as
int main
{
@class_name@ simulator;
...
}
to be able to replace the @class_name@ using AC_CONFIG_FILES.
I was thinking to write in the configure.in something like
class_name="class1"
AC_CONFIG_FILES(class1.cpp)
class_name="class2"
AC_CONFIG_FILES(class2.cpp)
and so on...
The problem is that AC_CONFIG_FILES will look for a class1.cpp.in,
class2.cpp.in while I would like it to always look for the default
main.cpp.in.
Any idea of how to do that?
Sincerely
Patrick
==
Patrick Guio
Institute of Physics, University of Oslo
P.O. box 1048, Blindern, N-0316 Oslo
Tel : (+47) 22 84 40 60 - Fax : (+47) 22 85 56 71
E-mail : [EMAIL PROTECTED]
URL : http://folk.uio.no/~patricg
AM_PATH_PYTHON(version) does not work properly?
Dear all, I have updated my autoconf/automake/libtool package to aclocal (GNU automake) 1.5a autoconf (GNU Autoconf) 2.52g automake (GNU automake) 1.5a libtoolize (GNU libtool) 1.4c and have included a AM_PATH_PYTHON(2.0) in configure.in I am running RH7.2 and have several python commands available. The default one is python and is version 1.5, there are in addition python2 and python2.1 all of them coming from rpm's. The problem is that when I run configure, it does not check all the possibilities as it should do (I have looked at the file python.m4) and just stop after having tried /usr/bin/python (which is 1.5) without testing other possibilties. checking for python... /usr/bin/python checking if Python version >= 2... configure: error: too old I notice in addition that in python.m4 AC_PATH_PROG(PYTHON, python python2.1 python2.0 python1.6 python1.5) May be there should also be python2? Sincerely Patrick
HOWTO "compile" script like progs
Dear all, I have shell bourne shell scripts and python (version 2) scripts. When running make, I would like to make them executable, i.e. to write a valid executable path in #!path_to_executable_shell_or_program at the beginning of the file. I would appreciate any help to configure Makefile.am to do that. Sincerely Patrick
Building c++ library with cxx/osf with libtool
Dear all
I have now been able to build c++ library on a alphaev6-dec-osf5.0
with templates using cxx
I had to specify in aclocal.m4 instead of
>old_archive_cmds='$AR $AR_FLAGS $oldlib$oldobjs$old_deplibs'
Note that by giving the option -MD one create a file with dependencies
(same style) called .o.d and the code is compiled!
Do you think it could be possible to insert this in the libtool?
Maybe automake/depcomp has to be modified to be able to use the option -MD
with the cxx compaq compiler for osf machines?
Sincerely
Patrick Guio
==
Patrick Guio
Institute of Physics, University of Oslo
P.O. box 1048, Blindern, N-0316 Oslo
Tel : (+47) 22 84 40 60 - Fax : (+47) 22 85 56 71
E-mail : [EMAIL PROTECTED]
URL : http://www.fys.uio.no
problem compiling on DEC with dependencies (cxx -M)
Dear all
I am not sure if this is to be adressed to libtool or maybe automake
since the problem might come from depcom...
Anyway I am trying to build a c++ library using libtool on a
alphaev6-dec-osf5.0
using cxx.
These set up should allow to archive correctly
# The archiver.
AR="ar"
AR_FLAGS="-rv"
RANLIB="ar ts"
old_archive_cmds="\$AR \$AR_FLAGS \$oldlib
\${libname}_la/*.o\$oldobjs\$old_deplibs~\$RANLIB\$oldlib"
If a directory of templates are created in ./\${libname}_la for example.
Now when using dependency tracking the mode choosen is
checking dependency style of cxx... conftest.o: conftest.c
conftest.o: conftest.h
dashmstdout
When running
% make libutilities_la-parser.lo
source='parser.cpp' object='libutilities_la-parser.lo' libtool=yes \
depfile='.deps/libutilities_la-parser.Plo'
tmpdepfile='.deps/libutilities_la-parser.TPlo' \
depmode=dashmstdout /bin/ksh ../depcomp \
/bin/ksh ../libtool --mode=compile cxx
-DPACKAGE=\"mudfas\" -DVERSION=\"0.9\" -DHAVE_LIBM=1 -DSTDC_HEADERS=1
-I. -I. -I. -DHDF -I/astro/local/opt/HDF_4.1r3/4.1r3_digunix/include
-I/mn/sothi/u1/patrickg/src/blitz -DFLOAT_FIELD -ptr libutilities_la
-nocompress -std strict_ansi -DBZ_DISABLE_XOPEN_SOURCE -ieee -c -o
libutilities_la-parser.lo `test -f parser.cpp || echo './'`parser.cpp
cxx -DPACKAGE=\"mudfas\" -DVERSION=\"0.9\" -DHAVE_LIBM=1 -DSTDC_HEADERS=1
-I. -I. -I. -DHDF -I/astro/local/opt/HDF_4.1r3/4.1r3_digunix/include
-I/mn/sothi/u1/patrickg/src/blitz -DFLOAT_FIELD -ptr libutilities_la
-nocompress -std strict_ansi -DBZ_DISABLE_XOPEN_SOURCE -ieee -c parser.cpp
-o libutilities_la-parser.o
echo timestamp > libutilities_la-parser.lo
Surprise, there is no libutilities_la-parser.o!
I have put a set -x in top of libtool and in order to find dependencies
the compiler is ran with the option -M
The problem is that when specifying -M with cxx even though you put also
the options -c -o $obj you don't create the .o file.
And it looks like that the .o is removed first and then the cxx -M is run
without running again cxx alone, therefore the .o is not created.
Sincerely
Patrick
==
Patrick Guio
Institute of Physics, University of Oslo
P.O. box 1048, Blindern, N-0316 Oslo
Tel : (+47) 22 84 40 60 - Fax : (+47) 22 85 56 71
E-mail : [EMAIL PROTECTED]
URL : http://www.fys.uio.no
ifeq/else/endif problem
Dear all I am trying to insert a conditional part in a Makefile.am in the following way : ## 2-dimensions library libmudfas2d_la_SOURCES = $(MUDSRC) ifeq ($(CXX),cxx) libmudfas2d_la_CXXFLAGS = -ptr mudfas2d -DDIM=2 libmudfas2d_la_LDFLAGS = mudfas2d/*.o -version-info 0:0:0 else libmudfas2d_la_CXXFLAGS = -DDIM=2 libmudfas2d_la_LDFLAGS = -version-info 0:0:0 endif But when running automake I get % automake -a -c --include-deps src/Makefile.am:24: endif without if src/Makefile.am:31: else without if src/Makefile.am:34: endif without if src/Makefile.am:41: else without if src/Makefile.am:44: endif without if If I look at Makefile.in, I get ifeq ($(CXX),cxx) libmudfas2d_la_CXXFLAGS = -ptr mudfas2d -DDIM=2 libmudfas2d_la_LDFLAGS = mudfas2d/*.o -version-info 0:0:0 libmudfas2d_la_CXXFLAGS = -DDIM=2 libmudfas2d_la_LDFLAGS = -version-info 0:0:0 Does automake not recognise GNU make instructions ?! Sincerely Patrick == Patrick Guio Institute of Physics, University of Oslo P.O. box 1048, Blindern, N-0316 Oslo Tel : (+47) 22 84 40 60 - Fax : (+47) 22 85 56 71 E-mail : [EMAIL PROTECTED] URL : http://www.fys.uio.no
More dependencies II
I wonder whether it's actually possible to use depcomp with _LDADD object files, like object with different compilation flags? It looks like that the files ~/.deps/*.Po are created while configure is run when detected in _SOURCES files but not _LDADD. Sincerely Patrick -- Forwarded message -- Date: Mon, 23 Oct 2000 10:47:21 +0200 (CEST) From: Patrick Guio <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: More dependencies... Refering to my earlier mail today,I have a comment about .cpp.o: source='$<' object='$@' libtool=no \ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \ $(CXXDEPMODE) $(depcomp) \ $(CXXCOMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$< The name of the dependency file is connected to the source file, not the object file, it should maybe better to build the name with the object file since the object might have been compiled with different defines flags. In my case I have a list of sources for a library MUDDIR = . UTILSRC = $(MUDDIR)/argparsing.cpp $(MUDDIR)/integrate.cpp MUDSRC = $(MUDDIR)/init.cpp $(MUDDIR)/lop.cpp $(MUDDIR)/mudfas.cpp\ $(MUDDIR)/prolon.cpp $(MUDDIR)/qnc.cpp $(MUDDIR)/restrict.cpp\ $(MUDDIR)/restrict_ops.cpp $(MUDDIR)/restrictphi.cpp\ $(MUDDIR)/smooth.cpp $(MUDDIR)/smooth_ops.cpp This library is compiled in 2d (-DDIM=2) and 3d (-DDIM=3) and I have MUD2DOBJ := $(patsubst %.cpp, %2d.o, $(MUDSRC)) MUD3DOBJ := $(patsubst %.cpp, %3d.o, $(MUDSRC)) $(MUD2DOBJ): %2d.o: %.cpp source='$<' object='$@' libtool=no \ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \ $(CXXDEPMODE) $(depcomp) \ $(CXXCOMPILE) $(INCLUDES) -DDIM=2 -c -o $@ `test -f $< || echo '$(srcdir)/'`$< $(MUD3DOBJ): %3d.o: %.cpp source='$<' object='$@' libtool=no \ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \ $(CXXDEPMODE) $(depcomp) \ $(CXXCOMPILE) $(INCLUDES) -DDIM=3 -c -o $@ `test -f $< || echo '$(srcdir)/'`$< But only '$(patsubst %.cpp, %.Po, $(MUDSRC))' are created. Sincerely Patrick Guio
More dependencies...
Refering to my earlier mail today,I have a comment about .cpp.o: source='$<' object='$@' libtool=no \ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \ $(CXXDEPMODE) $(depcomp) \ $(CXXCOMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$< The name of the dependency file is connected to the source file, not the object file, it should maybe better to build the name with the object file since the object might have been compiled with different defines flags. In my case I have a list of sources for a library MUDDIR = . UTILSRC = $(MUDDIR)/argparsing.cpp $(MUDDIR)/integrate.cpp MUDSRC = $(MUDDIR)/init.cpp $(MUDDIR)/lop.cpp $(MUDDIR)/mudfas.cpp\ $(MUDDIR)/prolon.cpp $(MUDDIR)/qnc.cpp $(MUDDIR)/restrict.cpp\ $(MUDDIR)/restrict_ops.cpp $(MUDDIR)/restrictphi.cpp\ $(MUDDIR)/smooth.cpp $(MUDDIR)/smooth_ops.cpp This library is compiled in 2d (-DDIM=2) and 3d (-DDIM=3) and I have MUD2DOBJ := $(patsubst %.cpp, %2d.o, $(MUDSRC)) MUD3DOBJ := $(patsubst %.cpp, %3d.o, $(MUDSRC)) $(MUD2DOBJ): %2d.o: %.cpp source='$<' object='$@' libtool=no \ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \ $(CXXDEPMODE) $(depcomp) \ $(CXXCOMPILE) $(INCLUDES) -DDIM=2 -c -o $@ `test -f $< || echo '$(srcdir)/'`$< $(MUD3DOBJ): %3d.o: %.cpp source='$<' object='$@' libtool=no \ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \ $(CXXDEPMODE) $(depcomp) \ $(CXXCOMPILE) $(INCLUDES) -DDIM=3 -c -o $@ `test -f $< || echo '$(srcdir)/'`$< But only '$(patsubst %.cpp, %.Po, $(MUDSRC))' are created. Sincerely Patrick Guio
More about dependencies...
Deal all
I refer to my earlier mails about problem with c++ dependencies. I don't
know whether this is a bug but I found out why I could not make
dependencies tracking working correctly.
My code consists of several directories
~
~/src
~/tests
and so on
~/Makefile.am does not contain so much
~/src is a directory with common c++ headers and source codes while
~/tests contains source codes to build and test.
When I run automake (-a -c --include-deps --force-missing) 'depcomp' were
installed in ~/src and ~/tests but *not* in ~
And there is the problem: when running configure I always got the messages
checking dependency style of g++... none
checking dependency style of gcc... none
until I manually add a ~/depcomp
Then
checking dependency style of g++... gcc
checking dependency style of gcc... gcc
Why is a ~/depcomp necessary in ~/ since I don't have any code there?
Sincerely
Patrick Guio
==
Patrick Guio
Institute of Physics, University of Oslo
P.O. box 1048, Blindern, N-0316 Oslo
Tel : (+47) 22 84 40 60 - Fax : (+47) 22 85 56 71
E-mail : [EMAIL PROTECTED]
URL : http://www.fys.uio.no
Re: dependencies in c++
On 19 Oct 2000, Raja R Harinath wrote: > Patrick Guio <[EMAIL PROTECTED]> writes: > > On 19 Oct 2000, Alexandre Oliva wrote: > > > On Oct 19, 2000, Patrick Guio <[EMAIL PROTECTED]> wrote: > > > > I really have problems to get the dependencies stuff to work correctly. I > > > > can see that some depcomp files are installed in my subdirectories but if > > > > I touch a .h file the stuff is not rebuilt. > > > > > > Which compiler are you using? The new dependency-tracking code in > > > automake only enables dependency tracking by default if the compiler > > > can generate dependencies as a side-effect of compilation. In other > > > cases, you have enable it explicitly. Run `configure --help' for the > > > options. > > > > I use mainly g++ but also cxx and KCC. When running > > % configure --enable-dependency-tracking > > I get the following: > > > > > > checking whether the C++ compiler works... yes > > > > checking dependency style of g++... (cached) none > > > > Does it has something to do with my problem? > > I use autoconf/automake/libtool which I get from cvs and the last I have > > successfully compiled is less than 1 month. > > Did you remove config.cache before rerunning the configure? > 'config.cache' may have the results of a previous run where you didn't > --enable-dependency-tracking, or it may have had the results for a > different compiler. > I don't have any config.cache! But at the end of config.log I have a list of variables Cache variables: | ac_cv_build='i686-pc-linux-gnu' | ac_cv_build_alias='i686-pc-linux-gnu' | ac_cv_c_compiler_gnu='yes' | ac_cv_cxx_compiler_gnu='yes' | ac_cv_env_CC_set='' | ac_cv_env_CC_value='' | ac_cv_env_CFLAGS_set='' | ac_cv_env_CFLAGS_value='' | ac_cv_env_CPPFLAGS_set='' | ac_cv_env_CPPFLAGS_value='' | ac_cv_env_CXXFLAGS_set='' | ac_cv_env_CXXFLAGS_value='' | ac_cv_env_CXX_set='' | ac_cv_env_CXX_value='' | ac_cv_env_LDFLAGS_set='' | ac_cv_env_LDFLAGS_value='' | ac_cv_env_build_alias_set='' | ac_cv_env_build_alias_value='' . and so on... Are you talking about that? Sincerely Patrick
Error message
Dear all I have written a Makefile.am containing the creation of a library conditionnaly if a --enable-lib is present. I get the following message when running automake % automake -a -c --include-deps automake: src/Makefile.am: warning: automake does not support libmudfas2d_la_LDFLAGS being defined conditionally automake: src/Makefile.am: warning: automake does not support libmudfas3d_la_LDFLAGS being defined conditionally Do you have any tips? Sincerely Patrick Guio == Patrick Guio The Auroral Observatory, University of Tromsø N-9037 Tromsø, Norway Tel : (+47) 77 64 56 75 - Fax : (+47) 77 64 62 80 E-mail : [EMAIL PROTECTED] URL : http://www.phys.uit.no ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[Automake] header dependencies on compilation
Dear all I am trying to use the configure system to build a library/program but I get some problems with dependencies. I have a directory containing .cpp and .h files which I would like to compile in two libraries with different compilation flags lib_LTLIBRARIES = libpicsim3d.la libpicsim2d.la libpicsim3d_la_SOURCES = species.cpp beam.cpp scheduler.cpp libpicsim3d_la_LDFLAGS = -version-info 0:0:0 libpicsim3d_la_CXXFLAGS = -DDIMR=3 -DDIMV=3 libpicsim2d_la_SOURCES = species.cpp beam.cpp scheduler.cpp libpicsim2d_la_LDFLAGS = -version-info 0:0:0 libpicsim2d_la_CXXFLAGS = -DDIMR=2 -DDIMV=3 It works fine until I touch for example species.h or another header file in the directory, then the corresponding(s) cpp files are just linked again but not recompiled. I have tried to include the header files in the _SOURCES or/and _DEPENDENCIES variables but it does not help. What do I do wrong? In my old Makefiles, I used to have a depend target that run the makedepend for me. Is there something similar I can use with the configure system? Sincerely Patrick Guio Please reply to [EMAIL PROTECTED] as well. ___ Automake mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/automake
