Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 01 Feb 1999 23:08:09 -0800
From:      Kent Stewart <kstewart@3-cities.com>
To:        Greg Lehey <grog@lemis.com>
Cc:        "freebsd-questions@FreeBSD.org" <freebsd-questions@FreeBSD.ORG>
Subject:   Re: Make File Generator
Message-ID:  <36B6A459.F889B88E@3-cities.com>
References:  <36B5FF82.D89176C1@3-cities.com> <19990202094916.R71384@freebie.lemis.com> <36B68FF4.48331073@3-cities.com> <19990202162039.U76680@freebie.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I used the piped command and starts out with the program name:	a.f a1.f a2.f
... name.f ... z.f 

The line wraps many times <grin>.

I have downloaded the GMake Manual and I'm looking at adding the rules. It
will have to be broken into the separate modules.

Greg Lehey wrote:
> 
> On Monday,  1 February 1999 at 21:41:08 -0800, Kent Stewart wrote:
> > Greg Lehey wrote:
> >> On Monday,  1 February 1999 at 11:24:50 -0800, Kent Stewart wrote:
> >>> On most of the Unix systems I have used there is a make generator for
> >>> Fortran. I don't see such a product on FreeBSD for f77. I have a large
> >>> program, i.e., more than 300 modules, that was last used on a Cray. The
> >>> sources as provided do not contain a makefile. I would like to try and build
> >>> it on FreeBSD but would hate to have to create the makefile by hand <grin>.
> >>> Is there something like mkmf that will generate a makefile.
> >>
> >> Not that I know of.  Have you tried gmake?  It knows about Fortran
> >> programs.  You probably need very little to make a usable Makefile.
> >> For example, if you create a single executable out of your 300 .f
> >> programs, you might do:
> >>
> >>   $ ls *.f | xargs | sed 's/^/PROG:     /' > Makefile
> >>
> >> Substitute the name of your program for PROG.
> >
> > I had thought about gmake. The gmake manual is intimdating. It is easy to
> > modify something that is generated and works. Creating the makefile from
> > scratch is something else. I also assumed that I needed to supply parameters
> > to the veraious steps. Your suggested sequence was so simple that it was
> > worth it to see what it would do. The problem is that the main program
> > overwhelms the table and kills the build on the first module and continues
> > on. The message I get is that I have to supply -Nn802 to f77 for the main
> > program. I don't think it would matter if the table was extended for all of
> > the modules. I didn't capture the output; however, the defaults appear to
> > work for everything else. The other thing is that this process isn't
> > generating object output and it takes about 45 minutes to compile
> > everything. That becomes a serious problem because it recompiles everything,
> > everytime.
> 
> I'm not sure I understand this, but it doesn't sound right.  What does
> your Makefile look like?
> 
> > A make generator should create something that looks like
> >
> > stuff ...
> >
> > main.o : main.f
> >       f77 -? main.f
> > link1.o : link1.f
> >       f77 -? link1.f
> 
> No, a Makefile generator should *never* generate something like that
> unless each and every module needs a different command, which would be
> very poor style.  You can replace all of this stuff with:
> 
> .f.o:
>         f77 -? $<
> 
> This has the advantage that it will still work if you add modules to
> the directory.

I like that. It is KISS simple. There are actually two programs with some
modules being shared and not all but I'm not worrying about that right now.
It is easier to build each in their own directory.

> 
> > and etc. for all of the functions and subroutines. This depends on a ".o"
> > being created for each compiled module, which reduces the recompiles to the
> > changed module. I haven't seen an object file. The basic process is
> > complicated because f77 isn't a real compiler. It calls f2c which takes the
> > FORTRAN code and produces c code. Then, it compiles the c code with
> > gcc.
> 
> That shouldn't make any difference.
> 
> > A simple compile and make with f77 produces nothing but the a.out.
> 
> OK, I understand that.
> 
> > I am really trying to make this program run on a PC where I have to
> > cope with 32 bit floats and integers instead of 64 bit -
> > everythings.
> 
> When you say a PC, do you mean Microsoft?  FreeBSD runs on PCs, but it
> supports 64 bit doubles (I thought Microsoft did too).
> 

They all do. But when you do a bit mask on a 64-bit integer, you get a
different result than when you try to mask a double integer on a 32-bit
machine because you usually only get the least significant 32-bits masked.
DEC Alpha's and Cray's support 64 bit integer masks. As a personal project,
I am trying to run it on a PC running FreeBSD. Using the "ln" command to
create local files would permit a setup that doesn't work well in the MS
environment. The program doesn't need GUI and FreeBSD could be an ideal
home. This program and a couple of others typically crank for hours and then
writes out a few histories and results. The users change a few numbers and
run the new design. They occasionally let it run all weekend. All you need
is a good solid system that everybody can get to and then let it run. You
can't telnet to NT without add-on products and they have to sit at the
console. 

I have DEC's Visual Fortran on an NT workstation. I have compiled and linked
the program as a Win32 Console app but it dies on an internal problem during
debug. It turns out there are some differences between Fortran on Unix and
Fortran on Windows32. The big area seems to be how the compilers deal with
entry points. Some compilers expect the each call to the entry point to
supply the original argument list. Some compilers permit new arguments with
continued access to the original arguments. This program assumes that you
can introduce new arguments and still have access to the old. The Cray
compiler permited one style and the Dec compiler used the new style. There
aren't that many modules with entry points the might have to be modified
once I have something that can be modified, built and run in the debugger.


> To get object files for each source file, try making the Makefile like
> this:
> 
>   $ ls *.f | sed 's/.f$/.o/ | xargs | sed 's/^/PROG:     /' > Makefile
> 
> This will make the program dependent on the objects and not on the
> sources.

It looked like it was starting out right but complains about too many names.
I will have to create the rules version and see what it does.

I still haven't seen an option to create object output.


-- 
Kent Stewart
Richland, WA

mailto:kstewart@3-cities.com
http://www.3-cities.com/~kstewart/index.html

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36B6A459.F889B88E>