Re: naming convention for object files.
Hi Miles, thanks for the explanation. I had never hear of the SHORTNAME attribute before, this is good to know. nick On Thu, Oct 11, 2012 at 9:20 PM, Miles Bader wrote: > Nicolas Bock writes: >> libsomething_la_CPPFLAGS = -I../../ > ... >> the naming changed from a.F90 -> libsomething_la-a.lo to a.F90 -> >> a.lo. Very strange. > > It's an annoying, but documented, effect of using per-library CFLAGS: > when you do that, automake decides that it must generate unique object > files for that library, and so uses the library name as a prefix for > the object file. This is presumably because it's _possible_ -- > although I think very rare -- to use the same source file in multiple > libraries, and with per-library flags, the resulting object files may > actually differ (whereas without per-library flags, they'd be the > same). > > [I wish automake would only use the prefixes in cases where a source > file is _actually_ used in multiple libraries; since I think it almost > never happens that people actually do this, that would mean almost no > object files would use the prefix. Maybe that's annoying to implement > though...] > > You _can_ change the name of the prefix used, by setting the > "SHORTNAME" attribute, e.g. > > libbozo_la_SHORTNAME = bozo > > -miles > > -- > Once, adj. Enough.
Re: naming convention for object files.
Hello list, I found the reason for the difference in naming: In the second library I had lib_LTLIBRARIES = libsomething.la libsomething_la_CPPFLAGS = -I../../ when I changed that to AM_CPPFLAGS = -I../../ the naming changed from a.F90 -> libsomething_la-a.lo to a.F90 -> a.lo. Very strange. nick On Thu, Oct 11, 2012 at 11:51 AM, Nicolas Bock wrote: > Hello list, > > I am using libtool to compile a library of a bunch of F90 files. Those > files have various dependencies between them and since automake is not > capable of tracking those for Fortran I have to by hand add lines like > > a.lo : b.lo c.lo > > to Makefile.am. Unfortunately automake's naming convention for the > object files is not clear to me. For one library I am building in this > way it translates a.F90 to a.lo but for another it does a.F90 to > libsomething_la-a.lo. This makes writing dependency rules somewhat > difficult. What controls the naming of object files? As far as I can > tell, configure.ac and Makefile.am in the two libraries are > essentially identical but obviously I must be overlooking something. > > Thanks already, > > nick
naming convention for object files.
Hello list, I am using libtool to compile a library of a bunch of F90 files. Those files have various dependencies between them and since automake is not capable of tracking those for Fortran I have to by hand add lines like a.lo : b.lo c.lo to Makefile.am. Unfortunately automake's naming convention for the object files is not clear to me. For one library I am building in this way it translates a.F90 to a.lo but for another it does a.F90 to libsomething_la-a.lo. This makes writing dependency rules somewhat difficult. What controls the naming of object files? As far as I can tell, configure.ac and Makefile.am in the two libraries are essentially identical but obviously I must be overlooking something. Thanks already, nick
exclude generated sources from dist
Hello list, I can't figure out how to exclude some source files I generate with a script in the dist. The problem it seems is that I list the generated sources in the _SOURCES variable and the dist target automatically includes them. But I need to rebuild the sources at compile time of the package because they depend on what configure finds, so it doesn't make any sense to include those in the dist. Is this possible? Thanks, nick
Re: build the same source twice with different macros
Thanks all for the suggestions. I will give it a try... nick On Mon, Nov 15, 2010 at 14:08, Ralf Wildenhues wrote: > Hi Nicolas, > > * Nicolas Bock wrote on Mon, Nov 15, 2010 at 05:11:26PM CET: >> (1) I can use C++ and rewrite the function header as a template. >> (2) I can define a macro for the preprocessor that is either defined >> as "float" or "double" and then compile the function source twice, the >> first time with $CC -DFLOAT=float and the second time with $CC >> -DFLOAT=double. >> >> Is option (2) possible within automake without excessive hackery? > > Yes. > >> Is it advisable? Is there a third option that I might want to >> consider? > > I'd say it's normal mumbo jumbo. See 'info Automake true'. > > bin_PROGRAMS = foo > foo_SOURCES = ... (other sources) > foo_LDADD = libfood.a libfoof.a > > noinst_LIBRARIES = libfood.a libfoof.a > libfood_a_SOURCES = bar.c > libfoof_a_SOURCES = $(libfood_a_SOURCES) > libfood_a_CPPFLAGS = -DFLOAT=float > > Hope that helps. > > Cheers, > Ralf >
build the same source twice with different macros
Hello list, I have some functions written in C that take a floating point argument, e.g. void foos (float x); void food (double x); The function bodies are basically identical except of course for the different floating point types. In order to avoid having to write redundant code, I see 2 options: (1) I can use C++ and rewrite the function header as a template. (2) I can define a macro for the preprocessor that is either defined as "float" or "double" and then compile the function source twice, the first time with $CC -DFLOAT=float and the second time with $CC -DFLOAT=double. Is option (2) possible within automake without excessive hackery? Is it advisable? Is there a third option that I might want to consider? Thanks already for your opinions, nick
Re: config.guess and config.sub don't work properly when specifying CC
Thanks On Thu, Jan 14, 2010 at 16:24, Ralf Wildenhues wrote: > Hello Nicolas, > > * Nicolas Bock wrote on Thu, Jan 14, 2010 at 11:42:47PM CET: > > > * Nicolas Bock wrote on Wed, Jan 13, 2010 at 08:41:35PM CET: > > > > on Ubuntu 8.04 I find that if I specify CC when I run configure, the > > > > configure script dies when it runs config.sub. I get this output > > > > > > > > $ CC=/usr/local/gcc-4.3.0/bin/gcc ./config.guess > > > > x86_64-unknown-linux- > [...] > > I emailed the script maintainer. > > Thanks. > > > The current HEAD of his scripts fixes the > > problem I was having. Is it possible to include the current > > config.guess and config.sub in the next release of automake? > > Yes. The external scripts are synced before each release. I'll sync > them to git when I get back to the next round of Automake work. > > Cheers, > Ralf >
Re: config.guess and config.sub don't work properly when specifying CC
Hi Ralf,
I emailed the script maintainer. The current HEAD of his scripts fixes the
problem I was having. Is it possible to include the current config.guess and
config.sub in the next release of automake?
nick
On Wed, Jan 13, 2010 at 13:06, Ralf Wildenhues wrote:
> Hello Nicolas,
>
> * Nicolas Bock wrote on Wed, Jan 13, 2010 at 08:41:35PM CET:
> > on Ubuntu 8.04 I find that if I specify CC when I run configure, the
> > configure script dies when it runs config.sub. I get this output
> >
> > $ CC=/usr/local/gcc-4.3.0/bin/gcc ./config.guess
> > x86_64-unknown-linux-
> >
> > but when I run with the system compiler (gcc 4.2.4):
> >
> > $ ./config.guess
> > x86_64-unknown-linux-gnu
> >
> > config.sub does not like "x86_64-unknown-linux-" and dies.
>
> config.{guess,sub} are maintained by the email address listed in the
> comments at the beginning of the scripts. Please write there, don't
> forget to mention the $timestamp value of the script as well as the
> output of
> /usr/local/gcc-4.3.0/bin/gcc -v
>
> Thanks,
> Ralf
>
Re: config.guess and config.sub don't work properly when specifying CC
Thanks, I forwarded my original question.
nick
On Wed, Jan 13, 2010 at 13:06, Ralf Wildenhues wrote:
> Hello Nicolas,
>
> * Nicolas Bock wrote on Wed, Jan 13, 2010 at 08:41:35PM CET:
> > on Ubuntu 8.04 I find that if I specify CC when I run configure, the
> > configure script dies when it runs config.sub. I get this output
> >
> > $ CC=/usr/local/gcc-4.3.0/bin/gcc ./config.guess
> > x86_64-unknown-linux-
> >
> > but when I run with the system compiler (gcc 4.2.4):
> >
> > $ ./config.guess
> > x86_64-unknown-linux-gnu
> >
> > config.sub does not like "x86_64-unknown-linux-" and dies.
>
> config.{guess,sub} are maintained by the email address listed in the
> comments at the beginning of the scripts. Please write there, don't
> forget to mention the $timestamp value of the script as well as the
> output of
> /usr/local/gcc-4.3.0/bin/gcc -v
>
> Thanks,
> Ralf
>
config.guess and config.sub don't work properly when specifying CC
Hello list, on Ubuntu 8.04 I find that if I specify CC when I run configure, the configure script dies when it runs config.sub. I get this output $ CC=/usr/local/gcc-4.3.0/bin/gcc ./config.guess x86_64-unknown-linux- but when I run with the system compiler (gcc 4.2.4): $ ./config.guess x86_64-unknown-linux-gnu config.sub does not like "x86_64-unknown-linux-" and dies. I don't find this behavior on a gentoo installation or Ubuntu 9.10. The dist tar file is the same. Since the config.guess scripts I am using on the ubuntu and the gentoo systems are the same, I guess the problem lies outside config.guess. I have tried to understand what config.guess does, but haven't gotten very far, so I can't tell what's going on. nick
Re: subdirs that should not be configured
Hi John, thanks for the advice. I thought there might be a mechanism built into automake and autoconf to express this paradigm, but the command line option solution is great! Thanks, nick On Thu, 2009-07-09 at 11:39 -0600, John Calcote wrote: > Hi Nicolas, > > On 7/9/2009 11:13 AM, Nicolas Bock wrote: > > Hello list, > > > > I have the following problem: I want to add an external package to our > > own package. The external package is already configured in the sense > > that its maintainer ran "make dist" and I simply untared the tar file > > into some directory underneath our source tree. I add that directory to > > AC_CONFIG_SUBDIRS in our main configure.ac and to SUBDIRS in our main > > Makefile.am so that when I run our configure script I will also run the > > configure script of the source package. The problem I have now is that > > when I run autoreconf it descends into the external package and tries to > > remake the configure script in there. How can I avoid that from > > happening? > > > > You can use the autoreconf --no-recursive option. This will autoreconf > only the current directory. If you have sub-projects that need to be > recursed into, but you need to skip this one directory, then you can > create a simple shell script that contains simply: > > autoreconf --no-recursive . subdir1 subdir2... > > Then, run this shell script to autoreconf only the subdirectories you want. > > The real problem here is a mixture of paradigms. You want to treat some > directories (your own) as maintainer code, and other directories (your > third-party directories) as user code. > > Regards, > John
subdirs that should not be configured
Hello list, I have the following problem: I want to add an external package to our own package. The external package is already configured in the sense that its maintainer ran "make dist" and I simply untared the tar file into some directory underneath our source tree. I add that directory to AC_CONFIG_SUBDIRS in our main configure.ac and to SUBDIRS in our main Makefile.am so that when I run our configure script I will also run the configure script of the source package. The problem I have now is that when I run autoreconf it descends into the external package and tries to remake the configure script in there. How can I avoid that from happening? Thanks already, nick
Re: source code type detection
Thanks for the help On Wed, 2008-01-23 at 22:50 +, Harlan Stenn wrote: > Nick, > > > I wrote a Makefile.am which includes a source file called b.C, which is > > a C-source and not a C++-source. In configure.ac I have AC_PROG_CC. When > > I run automake I get the error message: > > > > Makefile.am: C++ source seen but `CXX' is undefined > > Makefile.am: The usual way to define `CXX' is to add `AC_PROG_CXX' > > Makefile.am: to `configure.ac' and run `autoconf' again. > > > > So I guess automake interprets b.C to be C++. How can I tell automake > > that it's really C? > > Make a BUILT_SOURCES rule that links/copies $(srcdir)/b.C to > ($builddir)/b.c and use b.c in your foo_SOURCES line. > > H signature.asc Description: This is a digitally signed message part
source code type detection
Hello list, I wrote a Makefile.am which includes a source file called b.C, which is a C-source and not a C++-source. In configure.ac I have AC_PROG_CC. When I run automake I get the error message: Makefile.am: C++ source seen but `CXX' is undefined Makefile.am: The usual way to define `CXX' is to add `AC_PROG_CXX' Makefile.am: to `configure.ac' and run `autoconf' again. So I guess automake interprets b.C to be C++. How can I tell automake that it's really C? Thanks, nick signature.asc Description: This is a digitally signed message part
