[Top][All Lists]
[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.
- .F fix to automake.in, Christian Holm Christensen, 2001/05/21
- Re: .F fix to automake.in, Akim Demaille, 2001/05/21
- Re: .F fix to automake.in, Christian Holm Christensen, 2001/05/21
- Re: .F fix to automake.in, Tom Tromey, 2001/05/22
- Re: .F fix to automake.in, Christian Holm Christensen, 2001/05/22
- Re: .F fix to automake.in, Tom Tromey, 2001/05/22
- Re: .F fix to automake.in, Tom Tromey, 2001/05/24