Re: automake-1.7.7 and AM_CFLAGS/CFLAGS
Harlan == Harlan Stenn [EMAIL PROTECTED] writes: Harlan I'm trying hard to keep the warnings, as I want the Harlan developers to write cleaner code... Ah, sorry. Then it's probably better not to append anything to CFLAGS from ./configure. Put all your extra flags in SOFTW_CFLAGS or KMOD_CFLAGS, AC_SUBST these, and define `AM_CFLAGS = $(SOFTW_CFLAGS)' or `AM_CFLAGS = $(KMOD_CFLAGS)' in each Makefile. Note that if you use per-target _CFLAGS, you will also have to append $(AM_CFLAGS) to each such variables. Probably only of these translation can be automated so you don't hand-edit your 100+ Makefiles. -- Alexandre Duret-Lutz
Re: Fortran 9x support
Hmmm... Seems I failed to read the right postings in the autoconf archive. I did some catching up and it all makes sense now. Sorry for the noise... Regards, Sander On donderdag, okt 9, 2003, at 20:29 Europe/Amsterdam, Steven G. Johnson wrote: On Thu, 9 Oct 2003, Sander Niemeijer wrote: I can understand keeping F77/FFLAGS/FLIBS/AC_PROG_F77 for backwards compatibility. However, the current approach is to keep using these macros and variables for f77 and use the new FC* ones only for f90 and upwards. My question is whether it is not possible to also include f77 in the FC approach? It depends on what you mean. If you have F77 code that is compatible with the latest Fortran standards, sure, you can compile it with $FC. - Only allow the user to use either AC_PROG_F77 or AC_PROG_FC (the old or the new way of doing fortran). I think you are missing the point here. The reason for keeping F77, FFLAGS, etcetera, is not just for compatibility with old Makefile.in files. The reason is that Fortran 77 and Fortran 9x are essentially different languages, and a number of people need to compile both in the same project, using separate compilers and flags. (This issue came up whenever Fortran 9x support was discussed on the autoconf mailing list.) So, it is essential that a user be able to call both AC_PROG_F77 and AC_PROG_FC simultaneously. This was the design goal (otherwise, AC_PROG_FC would just be an alias for AC_PROG_F77.) Steven
Civil Engineering Quiz
If you are unable to view the images in this email, please copy and paste the following url into your browser...http://www.haestad.com/cq_cq_20030514 This message is intended for civil engineers and water resource professionals. If it has reached [EMAIL PROTECTED] in error, reply to this message with a subject line of "stop". LSID: 12403-2115402
configure size problem
Hi all! Now Im public from my home page package of my current project. Project have about 100kb of headers and sources of main package and two libs configured with AC_CONFIG_SUBDIRS(). Every lib dir have configure, and main package have configure. All seems well, but every confgure have about 600kb! and gziped package have about 850kb. 100kb of sources gziped with GNU environment in 850kb distro. Can I reduce size of configure? In configure output I see many unrequed check, my configure.in attached to mail. Thanks, e - GNU not UNIX, GNU better :) AC_INIT([AUTHORS]) AC_CANONICAL_SYSTEM AM_INIT_AUTOMAKE(onion, 0.2) AC_PROG_CC AM_PROG_LIBTOOL AC_PROG_MAKE_SET AC_PROG_CXX AM_PATH_CPPUNIT(1.8.0) AM_CONDITIONAL(HAVE_CPPUNIT, test $CPPUNIT_LIBS) AC_CHECK_PROG(RANLIB, ranlib, ranlib, :) AC_CHECK_PROG(DLLTOOL, dlltool, dlltool, dlltool) AC_CHECK_PROG(AS, as, as, as) AC_CHECK_PROG(AR, ar, ar, ar) if test -d libregistry; then AC_CONFIG_SUBDIRS(libregistry) fi if test -d libeventqueue; then AC_CONFIG_SUBDIRS(libeventqueue) fi AC_OUTPUT([Makefile src/Makefile tests/Makefile])
Re: How one could integrate Automake in an IDE ?
Alain == Alain Magloire [EMAIL PROTECTED] writes: Alain I'm curious on how the autoXXX tools like automake etc .. can Alain be integrated nicely part of an IDE. So far what I've seen Alain is not suitable enough ... Alain If you know of a good integration, please send the URL. The only integration I'm aware of at all is with KDevelop. I've still never tried that :-( Alain I'm looking at the Multipage Editor design, when one tab Alain control(page) shows the raw source and the others shows a Alain different view of the source that can be edited by newbies Alain easily, of course with round-trip(i.e. the raw source Alain Makefile.am reflects the other views vice-versa). Yeah, that sounds pretty reasonable, if difficult. It probably makes sense to concentrate on a simple-but-usable subset of automake, at least at first. Otherwise, the problem you'll encounter is that a Makefile.am is pretty complicated to interpret. For instance, there are runtime conditionals and configure substitutions. Another thing to think about is whether to support having a Makefile.am in each directory. It might be simpler just to have a single master Makefile.am at the top level. There are a lot of other things a useful auto*/eclipse integration could do. We could talk here or on the CDT list, as you (and others) prefer... Tom
Re: precompiled header suggestion
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl This sounds tricky. Adding such a file as a dependency of each .o file adl means that _all_ of them will be updated whenever the .ghc changes. Good point. There are other possible approaches, though. For instance, for a given program, we could generate: am--program: $(program_BUILT_SOURCES) $(MAKE) program ... which is sort of like the BUILT_SOURCES implementation, but more targeted. That's sort of backward, since make program will no longer work as expected. But you get the idea... I suppose this is sort of secondary, and the main thing is just to have some automation for building the .gch file at all. adl Putting the .ghc in BUILT_SOURCES automatically will not work if adl the .ghc includes another BUILT_SOURCES indirectly (direct adl inclusion is ok because we can issue the dependency ourself). adl Maybe we can live with such a limitation? Yeah, there could be some problems here. But the user can always add an explicit dependency (just adding the .h to the gch file's _SOURCES would suffice). adl Also I presume some libraries will also want to install such adl files? Can they be installed? (Is this what install-pch is adl about in your libstdc++ quote?) If so, such installation also adl needs to be conditional. Honestly, I don't know too much about this. I'd suggest we leave open the possibility that they can be installed, though. adl Maybe it would be simpler to introduce a new primary Yeah. Another idea would be to recognize `*.gch' automatically in a _SOURCES variable corresponding to a program or library. Tom
insterest sought(urgent)
ATTN, I want to inform you that am fully interested in transacting business in your country.My name is Nicholas taylor a resident in Monrovia the capital city of Liberia,Due to the civil war going on in my currently presently i wish to buy properties eg, [THREE HOUSES] urgently so that i may relocate my entire family out of the war torn country. I will want you to give me more information of some properties and some areas in which i can invest some of this money.I hope to hear from you as soon as possible via my personal e-mail [EMAIL PROTECTED] Thanks for your co operation. Nicholas Taylor.
many warnings and errors ...
Hi, I get lot of warnings and errors I can´t handle when installing an application that runs ok with rh 7 - now it´s rh 9 and these problems appear : processing . Running libtoolize... You should update your `aclocal.m4' by running aclocal. Running aclocal ... Running autoheader... WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. aclocal.m4:1380: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/functions.m4:1277: AM_FUNC_OBSTACK is expanded from... aclocal.m4:1380: the top level autom4te: /usr/bin/m4 failed with exit status: 1 autoheader: /usr/bin/autom4te failed with exit status: 1 Running automake --gnu ... Makefile.am: installing `./INSTALL' Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: installing `./COPYING' Makefile.am: required file `./AUTHORS' not found Running autoconf ... aclocal.m4:1380: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/functions.m4:1277: AM_FUNC_OBSTACK is expanded from... aclocal.m4:1380: the top level autom4te: /usr/bin/m4 failed with exit status: 1 Running ./configure ... Can anyone help ? Thanks a lot -- A l e x Harlan == Harlan Stenn [EMAIL PROTECTED] writes: Harlan I'm trying hard to keep the warnings, as I want the Harlan developers to write cleaner code... Ah, sorry. Then it's probably better not to append anything to CFLAGS from ./configure. Put all your extra flags in SOFTW_CFLAGS or KMOD_CFLAGS, AC_SUBST these, and define `AM_CFLAGS = $(SOFTW_CFLAGS)' or `AM_CFLAGS = $(KMOD_CFLAGS)' in each Makefile. Note that if you use per-target _CFLAGS, you will also have to append $(AM_CFLAGS) to each such variables. Probably only of these translation can be automated so you don't hand-edit your 100+ Makefiles. -- Alexandre Duret-Lutz
Tutorial ?
Hi to all, can anyone forward a link to good automake and autoconf tutorials ? I need any information about it urgently. Thanks in advance -- A l e x
