bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: .F fix to automake.in


From: Akim Demaille
Subject: Re: .F fix to automake.in
Date: 21 May 2001 14:46:38 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)

>>>>> "Christian" == Christian Holm Christensen <address@hidden> writes:

Christian> OK, I tried something like

Christian>   lib_LTLIBRARIES = libFoo.la libFoo_la_SOURCES = foo.F
Christian> libFoo_la_LDFLAGS = -version-info $(SOVERSION)

Christian> with Automake 1.4f, Autoconf 2.13 and Libtool 1.4 and
Christian> everythings fine.

Excellent.  Gary will probably want to apply your original patch to
the 1.4p branch.

Christian> When will you release 1.5?

Some time in 2001 :)  It's in feature freeze.

Christian> Will it be in time for Debian GNU/Linux 2.3 (my GNU/Linux
Christian> dist of choice), and other GNU/Linux distributions next
Christian> release?

When is it scheduled?


Christian> Uh, one thing you may want to consider: G77 can be told to
Christian> expand is "include" (not #include) search paths via the -I
Christian> option.  So couldn't the compilation of Fortran77 files
Christian> ending in .f (i.e., not preprocessed code) also use the
Christian> INCLUDES variable?  I have loads of examples of source
Christian> files in src including headers from ../include, and I
Christian> really don't like to do

Christian>   FFLAGS += $(INCLUDES)

Is it portable to non GNU Fortran compilers?  Is `include' standard?
If you answered at least once `no', then it's probably out of the
scope of the GNU build system.  But I'm no definitive reference.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]