Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problem with a batch build script
40 views
Skip to first unread message
Luka Djigas
Jan 13, 2012, 8:49:15 PM1/13/12
to
I admit, it's been a while since I've last written batch build scripts
... and it shows.
However, I cannot, for the life of me, understand what this error is
supposed to mean, nor what could be wrong with the script or the
link-er.
@echo off
cls
set F90C=ifort
set F90FLAGS=/nologo /libs:qwin /c
set LLIBS=/MACHINE:x86 /SUBSYSTEM:WINDOWS /NODEFAULTLIB:"libcmtd"
set SLINK=link
if "%1"==" " goto MISSING
%F90C% %1 %2 %3 %4 %5 %6 %7 %8 %9 %F90FLAGS%
%SLINK% %1 %2 %3 %4 %5 %6 %7 %8 %9 %LLIBS% /exe:%~n1.exe
echo %1.exe created! :)
goto END
:MISSING
echo Missing a filename maybe?
goto END
:END
@echo on
The error, upon invoking the script
qwin first.f90 second.f90
is
fatal error LNK1107: invalid or corrupt file: cannot read at 0x46
Does anyone know what could be wrong with it, or has encountered
anything like that before?
Environment: Windows XP/ifort
-- Luka
... and it shows.
However, I cannot, for the life of me, understand what this error is
supposed to mean, nor what could be wrong with the script or the
link-er.
@echo off
cls
set F90C=ifort
set F90FLAGS=/nologo /libs:qwin /c
set LLIBS=/MACHINE:x86 /SUBSYSTEM:WINDOWS /NODEFAULTLIB:"libcmtd"
set SLINK=link
if "%1"==" " goto MISSING
%F90C% %1 %2 %3 %4 %5 %6 %7 %8 %9 %F90FLAGS%
%SLINK% %1 %2 %3 %4 %5 %6 %7 %8 %9 %LLIBS% /exe:%~n1.exe
echo %1.exe created! :)
goto END
:MISSING
echo Missing a filename maybe?
goto END
:END
@echo on
The error, upon invoking the script
qwin first.f90 second.f90
is
fatal error LNK1107: invalid or corrupt file: cannot read at 0x46
Does anyone know what could be wrong with it, or has encountered
anything like that before?
Environment: Windows XP/ifort
-- Luka
Nasser M. Abbasi
Jan 13, 2012, 10:51:17 PM1/13/12
to
On 1/13/2012 7:49 PM, Luka Djigas wrote:
> I admit, it's been a while since I've last written batch build scripts
> ... and it shows.
<snip DOS batch>
> I admit, it's been a while since I've last written batch build scripts
> ... and it shows.
I can't help you with this, as I gave up writing DOS batch scripts
long time ago.
My advice is to throw DOS batch scripts away. You have much better options
these days:
1. get cygwin for windows (free), and write all your scripts in a real scripting
language (bash)
2. get oracle VM box (free), install Linux, mount your windows disk
from Linux, and and write all your scripts in a real scripting
language (bash) (this is what I do now).
If you work somewhere where they still use DOS for scripts, you
can educate them to change to Bash.
--Nasser
mecej4
Jan 13, 2012, 11:14:58 PM1/13/12
to
On 1/13/2012 7:49 PM, Luka Djigas wrote:
script: it is going to try to link source files, find that the source
files do not have the features expected of .OBJ files, and give up with
loud complaints.
--mecej4
glen herrmannsfeldt
Jan 13, 2012, 11:52:33 PM1/13/12
to
Nasser M. Abbasi <n...@12000.org> wrote:
> On 1/13/2012 7:49 PM, Luka Djigas wrote:
>> I admit, it's been a while since I've last written batch build scripts
>> ... and it shows.
> <snip DOS batch>
> I can't help you with this, as I gave up writing DOS batch scripts
> long time ago.
> My advice is to throw DOS batch scripts away.
> You have much better options these days:
(snip of suggestions)
> On 1/13/2012 7:49 PM, Luka Djigas wrote:
>> I admit, it's been a while since I've last written batch build scripts
>> ... and it shows.
> <snip DOS batch>
> I can't help you with this, as I gave up writing DOS batch scripts
> long time ago.
> My advice is to throw DOS batch scripts away.
> You have much better options these days:
MS had nmake, more or less an implementation of unix make,
many many years ago. The old MS make wasn't so good, but still
better than a DOS batch file.
Otherwise, I believe that link wants the name without any extension,
or with an .OBJ extension.
The compiler may or may not need an extension. The script looks like
it would work if the compiler didn't, and you didn't put one on
the command line.
-- glen
Luka Djigas
Jan 14, 2012, 7:21:14 AM1/14/12
to
On Fri, 13 Jan 2012 21:51:17 -0600, "Nasser M. Abbasi" <n...@12000.org>
wrote:
>On 1/13/2012 7:49 PM, Luka Djigas wrote:
>> I admit, it's been a while since I've last written batch build scripts
>> ... and it shows.
>
><snip DOS batch>
>
Uhmm, I'm not using DOS. What made you think that?
cmd in Windows is not DOS.
<snip>
>My advice is to throw DOS batch scripts away. You have much better options
>these days:
>
>1. get cygwin for windows (free), and write all your scripts in a real scripting
>language (bash)
>
>2. get oracle VM box (free), install Linux, mount your windows disk
>from Linux, and and write all your scripts in a real scripting
>language (bash) (this is what I do now).
Unfortunatelly, not only do some of my programs depend on cmd commands,
I also don't like the idea of changing shells/even less an OS, and/or
learning a whole new environment with its inherent set of problems.
My coleagues also probably wouldn't appreciate it much.
As much as I have respect for Linux, my "home" is on Windows for now.
-- Luka
wrote:
>On 1/13/2012 7:49 PM, Luka Djigas wrote:
>> I admit, it's been a while since I've last written batch build scripts
>> ... and it shows.
>
><snip DOS batch>
>
cmd in Windows is not DOS.
<snip>
>My advice is to throw DOS batch scripts away. You have much better options
>these days:
>
>1. get cygwin for windows (free), and write all your scripts in a real scripting
>language (bash)
>
>2. get oracle VM box (free), install Linux, mount your windows disk
>from Linux, and and write all your scripts in a real scripting
>language (bash) (this is what I do now).
I also don't like the idea of changing shells/even less an OS, and/or
learning a whole new environment with its inherent set of problems.
My coleagues also probably wouldn't appreciate it much.
As much as I have respect for Linux, my "home" is on Windows for now.
-- Luka
Luka Djigas
Jan 14, 2012, 8:26:55 AM1/14/12
to
On Fri, 13 Jan 2012 22:14:58 -0600, mecej4 <mec...@NOSPAM.operamail.com>
wrote:
>
>Turn on the echo and look at the linking command that comes out of the
>script: it is going to try to link source files, find that the source
>files do not have the features expected of .OBJ files, and give up with
>loud complaints.
>
>--mecej4
Yes, it seems there were two problems. The first one - the linker not
getting files with the .obj extension is now solved.
However, the second still remains.
I have %1 .... %9.
Since I'm passing files to the linker as
%~n1 (<-filename) .obj
in this manner
it results in (if only two files are actually compiled) the linker
being passed a command that looks like this
link first.obj second.obj .obj .obj .obj ...
Do you know perhaps how to avoid this behaviour?
(if %3 does not exist disregard the part that is "attached" to it
%~n3.obj)
-- Luka
p.s. Just for anyone asking, I know there is a make utility for Windows
(a native port), but I find makefiles terribly hard to read. Maybe I'm
just not used to them. And generally they tend to be longer then plain
old batch files.
wrote:
>
>Turn on the echo and look at the linking command that comes out of the
>script: it is going to try to link source files, find that the source
>files do not have the features expected of .OBJ files, and give up with
>loud complaints.
>
>--mecej4
getting files with the .obj extension is now solved.
However, the second still remains.
I have %1 .... %9.
Since I'm passing files to the linker as
%~n1 (<-filename) .obj
in this manner
it results in (if only two files are actually compiled) the linker
being passed a command that looks like this
link first.obj second.obj .obj .obj .obj ...
Do you know perhaps how to avoid this behaviour?
(if %3 does not exist disregard the part that is "attached" to it
%~n3.obj)
-- Luka
p.s. Just for anyone asking, I know there is a make utility for Windows
(a native port), but I find makefiles terribly hard to read. Maybe I'm
just not used to them. And generally they tend to be longer then plain
old batch files.
e p chandler
Jan 14, 2012, 8:56:24 AM1/14/12
to
"Luka Djigas" wrote in message
news:3d03h7la7ci6c17nm...@4ax.com...
On Fri, 13 Jan 2012 22:14:58 -0600, mecej4 <mec...@NOSPAM.operamail.com>
wrote:
>
>Turn on the echo and look at the linking command that comes out of the
>script: it is going to try to link source files, find that the source
>files do not have the features expected of .OBJ files, and give up with
>loud complaints.
>
>--mecej4
Yes, it seems there were two problems. The first one - the linker not
getting files with the .obj extension is now solved.
However, the second still remains.
I have %1 .... %9.
Since I'm passing files to the linker as
%~n1 (<-filename) .obj
in this manner
it results in (if only two files are actually compiled) the linker
being passed a command that looks like this
link first.obj second.obj .obj .obj .obj ...
Do you know perhaps how to avoid this behaviour?
(if %3 does not exist disregard the part that is "attached" to it
%~n3.obj)
-- Luka
----> This should work with a variable number of command line arguments:
for %%f in (%1 %2 %3 %4 %5 %6 %7 %8 %9) do link %%f.obj
-- Elliot
news:3d03h7la7ci6c17nm...@4ax.com...
On Fri, 13 Jan 2012 22:14:58 -0600, mecej4 <mec...@NOSPAM.operamail.com>
wrote:
>
>Turn on the echo and look at the linking command that comes out of the
>script: it is going to try to link source files, find that the source
>files do not have the features expected of .OBJ files, and give up with
>loud complaints.
>
>--mecej4
Yes, it seems there were two problems. The first one - the linker not
getting files with the .obj extension is now solved.
However, the second still remains.
I have %1 .... %9.
Since I'm passing files to the linker as
%~n1 (<-filename) .obj
in this manner
it results in (if only two files are actually compiled) the linker
being passed a command that looks like this
link first.obj second.obj .obj .obj .obj ...
Do you know perhaps how to avoid this behaviour?
(if %3 does not exist disregard the part that is "attached" to it
%~n3.obj)
-- Luka
for %%f in (%1 %2 %3 %4 %5 %6 %7 %8 %9) do link %%f.obj
-- Elliot
glen herrmannsfeldt
Jan 14, 2012, 9:23:59 AM1/14/12
to
Luka Djigas <ldi...@at.gmail.com> wrote:
(snip)
It won't accept them with .F90, though.
(I now have the Watcom compiler and linker that I use if I want
to compile/link DOS, Windows, or OS/2 files. It is a much nicer linker
that accepts MS format .OBJ files, and will link them just fine.
It also has a very good overlay system. It also comes with wmake,
which is nicer than MS nmake and make.)
> it results in (if only two files are actually compiled) the linker
> being passed a command that looks like this
> link first.obj second.obj .obj .obj .obj ...
I think you can separately compile them, ignoring the failed messages
for files that don't exist, then link with
LINK %1 %2 %3 %4
But if you want to, you can do something like:
echo off
if exist %9.obj (
echo nine
) else if exist %8.obj (
echo eight
) else if exist %7.obj (
echo seven
) else if exist %6.obj (
echo six
) else if exist %5.obj (
echo five
) else if exist %4.obj (
echo four
) else if exist %3.obj (
echo three
) else if exist %2.obj (
echo two
) else if exist %1.obj (
echo one
) else echo none
Replace each echo with the appropriate LINK command.
(Do HELP IF to see how the IF command works.)
(snip)
is a lot easier. Among others, many things you don't have to say
over and over. You put a rule that says how to convert a .F90 to
a .OBJ, and it will use that rule unless you specify a different one.
-- glen
(snip)
> Yes, it seems there were two problems. The first one - the linker not
> getting files with the .obj extension is now solved.
> However, the second still remains.
> I have %1 .... %9.
> Since I'm passing files to the linker as
> %~n1 (<-filename) .obj
> in this manner
I believe the linker accepts them without the .OBJ.
> getting files with the .obj extension is now solved.
> However, the second still remains.
> I have %1 .... %9.
> Since I'm passing files to the linker as
> %~n1 (<-filename) .obj
> in this manner
It won't accept them with .F90, though.
(I now have the Watcom compiler and linker that I use if I want
to compile/link DOS, Windows, or OS/2 files. It is a much nicer linker
that accepts MS format .OBJ files, and will link them just fine.
It also has a very good overlay system. It also comes with wmake,
which is nicer than MS nmake and make.)
> it results in (if only two files are actually compiled) the linker
> being passed a command that looks like this
> link first.obj second.obj .obj .obj .obj ...
for files that don't exist, then link with
LINK %1 %2 %3 %4
But if you want to, you can do something like:
echo off
if exist %9.obj (
echo nine
) else if exist %8.obj (
echo eight
) else if exist %7.obj (
echo seven
) else if exist %6.obj (
echo six
) else if exist %5.obj (
echo five
) else if exist %4.obj (
echo four
) else if exist %3.obj (
echo three
) else if exist %2.obj (
echo two
) else if exist %1.obj (
echo one
) else echo none
Replace each echo with the appropriate LINK command.
(Do HELP IF to see how the IF command works.)
(snip)
> p.s. Just for anyone asking, I know there is a make utility for Windows
> (a native port), but I find makefiles terribly hard to read. Maybe I'm
> just not used to them. And generally they tend to be longer then plain
> old batch files.
Yes they are harder to read, but once you get used to them it
> (a native port), but I find makefiles terribly hard to read. Maybe I'm
> just not used to them. And generally they tend to be longer then plain
> old batch files.
is a lot easier. Among others, many things you don't have to say
over and over. You put a rule that says how to convert a .F90 to
a .OBJ, and it will use that rule unless you specify a different one.
-- glen
Luka Djigas
Jan 14, 2012, 10:44:18 AM1/14/12
to
On Sat, 14 Jan 2012 14:23:59 +0000 (UTC), glen herrmannsfeldt
<g...@ugcs.caltech.edu> wrote:
>But if you want to, you can do something like:
>
>echo off
>if exist %9.obj (
>echo nine
>) else if exist %8.obj (
>echo eight
>) else if exist %7.obj (
>echo seven
>) else if exist %6.obj (
>echo six
>) else if exist %5.obj (
>echo five
>) else if exist %4.obj (
>echo four
>) else if exist %3.obj (
>echo three
>) else if exist %2.obj (
>echo two
>) else if exist %1.obj (
>echo one
>) else echo none
>
>Replace each echo with the appropriate LINK command.
Actually wrote it similar to that, in the end. Was hoping for a more
<g...@ugcs.caltech.edu> wrote:
>But if you want to, you can do something like:
>
>echo off
>if exist %9.obj (
>echo nine
>) else if exist %8.obj (
>echo eight
>) else if exist %7.obj (
>echo seven
>) else if exist %6.obj (
>echo six
>) else if exist %5.obj (
>echo five
>) else if exist %4.obj (
>echo four
>) else if exist %3.obj (
>echo three
>) else if exist %2.obj (
>echo two
>) else if exist %1.obj (
>echo one
>) else echo none
>
>Replace each echo with the appropriate LINK command.
elegant solution though.
>(Do HELP IF to see how the IF command works.)
>
>Yes they are harder to read, but once you get used to them it
>is a lot easier. Among others, many things you don't have to say
>over and over. You put a rule that says how to convert a .F90 to
>a .OBJ, and it will use that rule unless you specify a different one.
>
>-- glen
True. But they got one disadvantage compared to .bat files. You have to
>is a lot easier. Among others, many things you don't have to say
>over and over. You put a rule that says how to convert a .F90 to
>a .OBJ, and it will use that rule unless you specify a different one.
>
>-- glen
make a .makefile for every program/project you're building. Which, if
you're writing a lot of small programs that you keep all in one
directory, is really not all that practical.
With batch scripts (I have one for command line programs, one for
DISLIN, one for ...) I can just call
build-dislin first.f90 second.f90 third.f90 ... and off it goes.
You probably understand what I'm getting at.
Maybe I'm just not familiar with .makefiles. Can something similar be
accomplished with them too? Also, can they be named differently for
every program you're building - not just .makefile?
-- Luka
Ron Shepard
Jan 14, 2012, 1:06:14 PM1/14/12
to
In article <2os2h7pc9n4mnnbau...@4ax.com>,
in a unix environment. in fact, it is rather odd to hear someone try
to defend a Windows-specific programming environment with that
argument.
This programming environment is the same everywhere, under any
operating system. There is even a POSIX subset environment that is
standardized if that is important. When you restrict yourself to
that, you are virtually guaranteed portability to any modern
computer, now or in the foreseeable future, from laptops to exaflops
supercomputers. Maybe even cell phones should be included in that
list? POSIX is an IEEE industry standard.
> As much as I have respect for Linux, my "home" is on Windows for now.
Linux is certainly popular, but it is not the standard that you
should aim for regarding portability. It is POSIX. This includes,
for example, Linux, AIX, HPUX, MacOSX, SunOS/Solaris, and even
Windows. When you combine POSIX with the various ANSI and ISO
language standards, you have quite a good platform to work with.
Regarding the make utility, yes that is also part of POSIX.
Programmers have a love/hate relationship with make. Anyone (yes I
mean *anyone*) could have designed a better utility than make 30
years ago. But that's not what happened, someone designed make and
it stuck, it is now part of the standard programming environment,
and it will remain so for the foreseeable future. So if you are
interested in becoming a serious programmer, and writing portable
programs that are used by other people, you should invest the effort
to learn how to use it. As quirky as it is, it only takes a few
hours to learn.
$.02 -Ron Shepard
Luka Djigas <ldi...@at.gmail.com> wrote:
> Unfortunatelly, not only do some of my programs depend on cmd commands,
> I also don't like the idea of changing shells/even less an OS, and/or
> learning a whole new environment with its inherent set of problems.
> My coleagues also probably wouldn't appreciate it much.
These are exactly the reasons that you should consider programming
> Unfortunatelly, not only do some of my programs depend on cmd commands,
> I also don't like the idea of changing shells/even less an OS, and/or
> learning a whole new environment with its inherent set of problems.
> My coleagues also probably wouldn't appreciate it much.
in a unix environment. in fact, it is rather odd to hear someone try
to defend a Windows-specific programming environment with that
argument.
This programming environment is the same everywhere, under any
operating system. There is even a POSIX subset environment that is
standardized if that is important. When you restrict yourself to
that, you are virtually guaranteed portability to any modern
computer, now or in the foreseeable future, from laptops to exaflops
supercomputers. Maybe even cell phones should be included in that
list? POSIX is an IEEE industry standard.
> As much as I have respect for Linux, my "home" is on Windows for now.
should aim for regarding portability. It is POSIX. This includes,
for example, Linux, AIX, HPUX, MacOSX, SunOS/Solaris, and even
Windows. When you combine POSIX with the various ANSI and ISO
language standards, you have quite a good platform to work with.
Regarding the make utility, yes that is also part of POSIX.
Programmers have a love/hate relationship with make. Anyone (yes I
mean *anyone*) could have designed a better utility than make 30
years ago. But that's not what happened, someone designed make and
it stuck, it is now part of the standard programming environment,
and it will remain so for the foreseeable future. So if you are
interested in becoming a serious programmer, and writing portable
programs that are used by other people, you should invest the effort
to learn how to use it. As quirky as it is, it only takes a few
hours to learn.
$.02 -Ron Shepard
Luka Djigas
Jan 14, 2012, 1:27:49 PM1/14/12
to
On Sat, 14 Jan 2012 12:06:14 -0600, Ron Shepard
<ron-s...@NOSPAM.comcast.net> wrote:
>In article <2os2h7pc9n4mnnbau...@4ax.com>,
> Luka Djigas <ldi...@at.gmail.com> wrote:
>
>These are exactly the reasons that you should consider programming
>in a unix environment. in fact, it is rather odd to hear someone try
>to defend a Windows-specific programming environment with that
>argument.
>
>This programming environment is the same everywhere, under any
>operating system. There is even a POSIX subset environment that is
>standardized if that is important. When you restrict yourself to
>that, you are virtually guaranteed portability to any modern
>computer, now or in the foreseeable future, from laptops to exaflops
>supercomputers. Maybe even cell phones should be included in that
>list? POSIX is an IEEE industry standard.
Don't take this the wrong way ... but I came here with a linker/batch
<ron-s...@NOSPAM.comcast.net> wrote:
>In article <2os2h7pc9n4mnnbau...@4ax.com>,
> Luka Djigas <ldi...@at.gmail.com> wrote:
>
>These are exactly the reasons that you should consider programming
>in a unix environment. in fact, it is rather odd to hear someone try
>to defend a Windows-specific programming environment with that
>argument.
>
>This programming environment is the same everywhere, under any
>operating system. There is even a POSIX subset environment that is
>standardized if that is important. When you restrict yourself to
>that, you are virtually guaranteed portability to any modern
>computer, now or in the foreseeable future, from laptops to exaflops
>supercomputers. Maybe even cell phones should be included in that
>list? POSIX is an IEEE industry standard.
build script problem.
Now you're suggesting I change an OS, learn a whole new environment and
change all my hard coded cmd commands in all my programs (that have been
working fine since the time of MS-DOS) ...
doesn't sound like a solution to me.
(though it reminds me of that joke about a fellow buying a boat in the
end :)
... not to mention the troubles I'll have when Windows programs try to
read my output files with Unix <eol>'s.
Sorry, not for now ... for what I do, Linux just doesn't cut it (in many
segments).
>Linux is certainly popular, but it is not the standard that you
>should aim for regarding portability. It is POSIX. This includes,
>for example, Linux, AIX, HPUX, MacOSX, SunOS/Solaris, and even
>Windows. When you combine POSIX with the various ANSI and ISO
>language standards, you have quite a good platform to work with.
>
>Regarding the make utility, yes that is also part of POSIX.
>Programmers have a love/hate relationship with make. Anyone (yes I
>mean *anyone*) could have designed a better utility than make 30
>years ago. But that's not what happened, someone designed make and
>it stuck, it is now part of the standard programming environment,
>and it will remain so for the foreseeable future. So if you are
>interested in becoming a serious programmer, and writing portable
>programs that are used by other people, you should invest the effort
>to learn how to use it. As quirky as it is, it only takes a few
>hours to learn.
>
.makefile be used to compile several programs (without hardcoding
anything in the makefile relevant to each of them).
Make that a few days ...
-- Luka
Luka Djigas
Jan 14, 2012, 5:32:11 PM1/14/12
to
On Sat, 14 Jan 2012 19:27:49 +0100, Luka Djigas <ldi...@at.gmail.com>
wrote:
<snip>
(but I'm still not switching an OS). Using the one from unxkit-tiny.
-- Luka
p.s. Anyone know how SCons rate for fortran needs? Any (obvious)
advantages over other build systems?
wrote:
<snip>
>>programs that are used by other people, you should invest the effort
>>to learn how to use it. As quirky as it is, it only takes a few
>>hours to learn.
>>
>
>I spend the whole afternoon today trying to figure out can (and how) one
>.makefile be used to compile several programs (without hardcoding
>anything in the makefile relevant to each of them).
>Make that a few days ...
>
>
>-- Luka
Had some luck with makefiles. Will give it one more shot to impress.
>>to learn how to use it. As quirky as it is, it only takes a few
>>hours to learn.
>>
>
>I spend the whole afternoon today trying to figure out can (and how) one
>.makefile be used to compile several programs (without hardcoding
>anything in the makefile relevant to each of them).
>Make that a few days ...
>
>
>-- Luka
(but I'm still not switching an OS). Using the one from unxkit-tiny.
-- Luka
p.s. Anyone know how SCons rate for fortran needs? Any (obvious)
advantages over other build systems?
Ron Shepard
Jan 14, 2012, 6:04:46 PM1/14/12
to
In article <3qh3h7h5jk8nuhrmn...@4ax.com>,
your one batch file problem. I just pointed out that your argument
for staying in that environment in the first place was misguided.
There are short term goals and there are long term goals, and
sometimes they are in conflict.
>
> doesn't sound like a solution to me.
> (though it reminds me of that joke about a fellow buying a boat in the
> end :)
>
> ... not to mention the troubles I'll have when Windows programs try to
> read my output files with Unix <eol>'s.
>
> Sorry, not for now ... for what I do, Linux just doesn't cut it (in many
> segments).
I did not suggest you switch to linux. Maybe you stopped reading
too soon? There are POSIX/unix programming environments within
Windows. Maybe you should consider using one of those in the future?
>
> >Linux is certainly popular, but it is not the standard that you
> >should aim for regarding portability. It is POSIX. This includes,
> >for example, Linux, AIX, HPUX, MacOSX, SunOS/Solaris, and even
> >Windows. When you combine POSIX with the various ANSI and ISO
> >language standards, you have quite a good platform to work with.
> >
> >Regarding the make utility, yes that is also part of POSIX.
> >Programmers have a love/hate relationship with make. Anyone (yes I
> >mean *anyone*) could have designed a better utility than make 30
> >years ago. But that's not what happened, someone designed make and
> >it stuck, it is now part of the standard programming environment,
> >and it will remain so for the foreseeable future. So if you are
> >interested in becoming a serious programmer, and writing portable
> >programs that are used by other people, you should invest the effort
> >to learn how to use it. As quirky as it is, it only takes a few
> >hours to learn.
> >
>
> I spend the whole afternoon today trying to figure out can (and how) one
> .makefile be used to compile several programs (without hardcoding
> anything in the makefile relevant to each of them).
> Make that a few days ...
If you are talking about building a set of small single-file
programs, then here is the usual approach.
.exe.F90:
<place the appropriate commands here>
This defines a "default rule" to build <program>.exe from a single
<program>.F90 file. I don't know what those DOS commands are, but
this should do the trick. If things are more complicated than that,
then of course you need to write specific dependencies for each of
your programs. However, that is not a bad thing because it
describes those dependencies to everyone else who will later build
or modify your programs.
Hope this helps.
$.02 -Ron Shepard
Luka Djigas <ldi...@at.gmail.com> wrote:
> On Sat, 14 Jan 2012 12:06:14 -0600, Ron Shepard
> <ron-s...@NOSPAM.comcast.net> wrote:
>
> >In article <2os2h7pc9n4mnnbau...@4ax.com>,
> > Luka Djigas <ldi...@at.gmail.com> wrote:
> >
> >These are exactly the reasons that you should consider programming
> >in a unix environment. in fact, it is rather odd to hear someone try
> >to defend a Windows-specific programming environment with that
> >argument.
> >
> >This programming environment is the same everywhere, under any
> >operating system. There is even a POSIX subset environment that is
> >standardized if that is important. When you restrict yourself to
> >that, you are virtually guaranteed portability to any modern
> >computer, now or in the foreseeable future, from laptops to exaflops
> >supercomputers. Maybe even cell phones should be included in that
> >list? POSIX is an IEEE industry standard.
>
> Don't take this the wrong way ... but I came here with a linker/batch
> build script problem.
>
> Now you're suggesting I change an OS, learn a whole new environment and
> change all my hard coded cmd commands in all my programs (that have been
> working fine since the time of MS-DOS) ...
Well no, I didn't suggest that you change everything just to solve
> On Sat, 14 Jan 2012 12:06:14 -0600, Ron Shepard
> <ron-s...@NOSPAM.comcast.net> wrote:
>
> >In article <2os2h7pc9n4mnnbau...@4ax.com>,
> > Luka Djigas <ldi...@at.gmail.com> wrote:
> >
> >These are exactly the reasons that you should consider programming
> >in a unix environment. in fact, it is rather odd to hear someone try
> >to defend a Windows-specific programming environment with that
> >argument.
> >
> >This programming environment is the same everywhere, under any
> >operating system. There is even a POSIX subset environment that is
> >standardized if that is important. When you restrict yourself to
> >that, you are virtually guaranteed portability to any modern
> >computer, now or in the foreseeable future, from laptops to exaflops
> >supercomputers. Maybe even cell phones should be included in that
> >list? POSIX is an IEEE industry standard.
>
> Don't take this the wrong way ... but I came here with a linker/batch
> build script problem.
>
> Now you're suggesting I change an OS, learn a whole new environment and
> change all my hard coded cmd commands in all my programs (that have been
> working fine since the time of MS-DOS) ...
your one batch file problem. I just pointed out that your argument
for staying in that environment in the first place was misguided.
There are short term goals and there are long term goals, and
sometimes they are in conflict.
>
> doesn't sound like a solution to me.
> (though it reminds me of that joke about a fellow buying a boat in the
> end :)
>
> ... not to mention the troubles I'll have when Windows programs try to
> read my output files with Unix <eol>'s.
>
> Sorry, not for now ... for what I do, Linux just doesn't cut it (in many
> segments).
too soon? There are POSIX/unix programming environments within
Windows. Maybe you should consider using one of those in the future?
>
> >Linux is certainly popular, but it is not the standard that you
> >should aim for regarding portability. It is POSIX. This includes,
> >for example, Linux, AIX, HPUX, MacOSX, SunOS/Solaris, and even
> >Windows. When you combine POSIX with the various ANSI and ISO
> >language standards, you have quite a good platform to work with.
> >
> >Regarding the make utility, yes that is also part of POSIX.
> >Programmers have a love/hate relationship with make. Anyone (yes I
> >mean *anyone*) could have designed a better utility than make 30
> >years ago. But that's not what happened, someone designed make and
> >it stuck, it is now part of the standard programming environment,
> >and it will remain so for the foreseeable future. So if you are
> >interested in becoming a serious programmer, and writing portable
> >programs that are used by other people, you should invest the effort
> >to learn how to use it. As quirky as it is, it only takes a few
> >hours to learn.
> >
>
> I spend the whole afternoon today trying to figure out can (and how) one
> .makefile be used to compile several programs (without hardcoding
> anything in the makefile relevant to each of them).
> Make that a few days ...
programs, then here is the usual approach.
.exe.F90:
<place the appropriate commands here>
This defines a "default rule" to build <program>.exe from a single
<program>.F90 file. I don't know what those DOS commands are, but
this should do the trick. If things are more complicated than that,
then of course you need to write specific dependencies for each of
your programs. However, that is not a bad thing because it
describes those dependencies to everyone else who will later build
or modify your programs.
Hope this helps.
$.02 -Ron Shepard
glen herrmannsfeldt
Jan 14, 2012, 7:35:17 PM1/14/12
to
Luka Djigas <ldi...@at.gmail.com> wrote:
(snip, I wrote)
> Actually wrote it similar to that, in the end. Was hoping for a more
> elegant solution though.
CMD isn't as powerful as unix shells, though a little better than
the COMMAND processor for DOS.
I think you can do loops, but I didn't try last night.
(snip on makefiles)
> True. But they got one disadvantage compared to .bat files. You have to
> make a .makefile for every program/project you're building. Which, if
> you're writing a lot of small programs that you keep all in one
> directory, is really not all that practical.
The idea is that the command all go into one makefile for all those
programs.
> With batch scripts (I have one for command line programs, one for
> DISLIN, one for ...) I can just call
> build-dislin first.f90 second.f90 third.f90 ... and off it goes.
> You probably understand what I'm getting at.
Sometimes I make the .cmd file to run make, as it saves just a few
characters of typing.
> Maybe I'm just not familiar with .makefiles. Can something similar be
> accomplished with them too? Also, can they be named differently for
> every program you're building - not just .makefile?
You can name it anything, and use the -f option.
make -f someothermakefile
Note, though, that in the usual case you don't need to do much.
Make knows how to compile programs without any help.
As a test, (on a linux system) I make a file, this.f, and, without
any makefile said
make this
f77 this.f -o this
make: f77: Command not found
make: *** [this] Error 127
So, make figured out how to compile and link the program, but I don't
have f77.
make FC=gfortran this
will do it.
If I make a Makefile with just one line:
FC=gfortran
I can now compile and link any single Fortran file.
There are default rules for that case.
But there is no way that make could know if more files were needed.
Now, add the line:
this: this.o that.o
which tells make to link this.o and that.o to generate that. Or, for DOS:
this.exe: this.obj that.obj
Now make knows to compile both this.f and that.f, but it fails at
link time because it doesn't know that they are gfortran .o files.
If I add
CC=gfortran
So that my Makefile now says:
FC=gfortran
CC=gfortran
this: this.o that.o
It will compile this.f and that.f, then link the two .o files.
Strange as it may seem, the gfortran command will compile C programs.
The cc command will compile, but not successfully link, Fortran
programs.
Anyway, so all you need to add to the Makefile is the dependency
in object files and make will figure out the rest.
Well, you might also need the dependencey for MOD files.
You can set FFLAGS to any compiler options, in the makefile, on
the make command line, or as an environment variable.
-- glen
(snip, I wrote)
>>But if you want to, you can do something like:
>>if exist %9.obj (
>>echo nine
(snip of eight more cases)
>>echo nine
> Actually wrote it similar to that, in the end. Was hoping for a more
> elegant solution though.
the COMMAND processor for DOS.
I think you can do loops, but I didn't try last night.
(snip on makefiles)
> True. But they got one disadvantage compared to .bat files. You have to
> make a .makefile for every program/project you're building. Which, if
> you're writing a lot of small programs that you keep all in one
> directory, is really not all that practical.
programs.
> With batch scripts (I have one for command line programs, one for
> DISLIN, one for ...) I can just call
> build-dislin first.f90 second.f90 third.f90 ... and off it goes.
> You probably understand what I'm getting at.
characters of typing.
> Maybe I'm just not familiar with .makefiles. Can something similar be
> accomplished with them too? Also, can they be named differently for
> every program you're building - not just .makefile?
make -f someothermakefile
Note, though, that in the usual case you don't need to do much.
Make knows how to compile programs without any help.
As a test, (on a linux system) I make a file, this.f, and, without
any makefile said
make this
f77 this.f -o this
make: f77: Command not found
make: *** [this] Error 127
So, make figured out how to compile and link the program, but I don't
have f77.
make FC=gfortran this
will do it.
If I make a Makefile with just one line:
FC=gfortran
I can now compile and link any single Fortran file.
There are default rules for that case.
But there is no way that make could know if more files were needed.
Now, add the line:
this: this.o that.o
which tells make to link this.o and that.o to generate that. Or, for DOS:
this.exe: this.obj that.obj
Now make knows to compile both this.f and that.f, but it fails at
link time because it doesn't know that they are gfortran .o files.
If I add
CC=gfortran
So that my Makefile now says:
FC=gfortran
CC=gfortran
this: this.o that.o
It will compile this.f and that.f, then link the two .o files.
Strange as it may seem, the gfortran command will compile C programs.
The cc command will compile, but not successfully link, Fortran
programs.
Anyway, so all you need to add to the Makefile is the dependency
in object files and make will figure out the rest.
Well, you might also need the dependencey for MOD files.
You can set FFLAGS to any compiler options, in the makefile, on
the make command line, or as an environment variable.
-- glen
glen herrmannsfeldt
Jan 14, 2012, 8:12:37 PM1/14/12
to
> Had some luck with makefiles. Will give it one more shot to impress.
> (but I'm still not switching an OS). Using the one from unxkit-tiny.
Original MS make wasn't much different from a script. It did everything
> (but I'm still not switching an OS). Using the one from unxkit-tiny.
in the order given, or not.
MS nmake, and unix make, figure out the dependence from the file and
do things in the right order. There is also Watcom's wmake, and,
I believe, ports of GNU make, which has many features not in the
usual unix make.
-- glen
Paul Anton Letnes
Jan 15, 2012, 2:33:41 AM1/15/12
to
stands for Cross-platform, and it works across windows (ymmv, I have
never used CMake in windows), macosx, and linux. Writing build scripts
in bash/cmd/dos is much less convenient than CMake or even good old Gnu
Make. CMake even features a GUI for the faint of heart, and lets you
specify (at least) 2 sets of compiler flags - one for "debug" and
another for "release".
Good luck
Paul
Paul Anton Letnes
Jan 15, 2012, 2:35:21 AM1/15/12
to
On 15.01.12 02:12, glen herrmannsfeldt wrote:
> Luka Djigas<ldi...@at.gmail.com> wrote:
>
> (snip)
>
>> Had some luck with makefiles. Will give it one more shot to impress.
>> (but I'm still not switching an OS). Using the one from unxkit-tiny.
>
>
> Original MS make wasn't much different from a script. It did everything
> in the order given, or not.
>
> MS nmake, and unix make, figure out the dependence from the file and
> do things in the right order.
Not quite. You have to specify the dependencies, and then make will do
> Luka Djigas<ldi...@at.gmail.com> wrote:
>
> (snip)
>
>> Had some luck with makefiles. Will give it one more shot to impress.
>> (but I'm still not switching an OS). Using the one from unxkit-tiny.
>
>
> Original MS make wasn't much different from a script. It did everything
> in the order given, or not.
>
> MS nmake, and unix make, figure out the dependence from the file and
> do things in the right order.
things in the right order. Not as convenient as, say, CMake, which
actually reads your code and figures out module dependencies etc.
Paul
glen herrmannsfeldt
Jan 15, 2012, 6:02:08 AM1/15/12
to
Paul Anton Letnes <paul.ant...@nospam.gmail.kthxbai.com> wrote:
(snip, I wrote)
dependence and dependencies, or maybe interdependence.
It is usual to write a unix Makefile top down. Starting with what is
desired, then what is needed to produce that, eventually to the
source files supplied. Unix make walks the tree, one direction, and
then processes the files, as specified, the other direction.
The Makefile supplied the first order dependencies, make has to find
the second, third, etc., dependencies.
The original MS make, on the other hand, did none of that. It was
more like a conditional script. You had to put everything in the right
order, or nothing much useful would happen at all. I used this before
unix make, I believe with version 4.0 of the C compiler, about the
same time as version 4.0 of the Fortran compiler.
At that point, there wasn't a driver like unix cc, that calls both
the compiler and linker. You had to compile by running the compiler,
and link by running LINK. You had to specify the appropriate libraries,
as there was no system to do that for you. Even the appropriate
standard C library, with model dependence and floating point software
or hardware versions.
-- glen
(snip, I wrote)
>> MS nmake, and unix make, figure out the dependence from the file and
>> do things in the right order.
> Not quite. You have to specify the dependencies, and then make will do
> things in the right order. Not as convenient as, say, CMake, which
> actually reads your code and figures out module dependencies etc.
OK, maybe I didn't say it right. Or maybe it is the difference between
>> do things in the right order.
> Not quite. You have to specify the dependencies, and then make will do
> things in the right order. Not as convenient as, say, CMake, which
> actually reads your code and figures out module dependencies etc.
dependence and dependencies, or maybe interdependence.
It is usual to write a unix Makefile top down. Starting with what is
desired, then what is needed to produce that, eventually to the
source files supplied. Unix make walks the tree, one direction, and
then processes the files, as specified, the other direction.
The Makefile supplied the first order dependencies, make has to find
the second, third, etc., dependencies.
The original MS make, on the other hand, did none of that. It was
more like a conditional script. You had to put everything in the right
order, or nothing much useful would happen at all. I used this before
unix make, I believe with version 4.0 of the C compiler, about the
same time as version 4.0 of the Fortran compiler.
At that point, there wasn't a driver like unix cc, that calls both
the compiler and linker. You had to compile by running the compiler,
and link by running LINK. You had to specify the appropriate libraries,
as there was no system to do that for you. Even the appropriate
standard C library, with model dependence and floating point software
or hardware versions.
-- glen
Paul Anton Letnes
Jan 16, 2012, 4:01:32 AM1/16/12
to
On 15.01.12 12:02, glen herrmannsfeldt wrote:
> Paul Anton Letnes<paul.ant...@nospam.gmail.kthxbai.com> wrote:
>
> (snip, I wrote)
>>> MS nmake, and unix make, figure out the dependence from the file and
>>> do things in the right order.
>
>> Not quite. You have to specify the dependencies, and then make will do
>> things in the right order. Not as convenient as, say, CMake, which
>> actually reads your code and figures out module dependencies etc.
>
> OK, maybe I didn't say it right. Or maybe it is the difference between
> dependence and dependencies, or maybe interdependence.
>
> It is usual to write a unix Makefile top down. Starting with what is
> desired, then what is needed to produce that, eventually to the
> source files supplied. Unix make walks the tree, one direction, and
> then processes the files, as specified, the other direction.
Right, and this is already much more useful than writing your own bash
> Paul Anton Letnes<paul.ant...@nospam.gmail.kthxbai.com> wrote:
>
> (snip, I wrote)
>>> MS nmake, and unix make, figure out the dependence from the file and
>>> do things in the right order.
>
>> Not quite. You have to specify the dependencies, and then make will do
>> things in the right order. Not as convenient as, say, CMake, which
>> actually reads your code and figures out module dependencies etc.
>
> OK, maybe I didn't say it right. Or maybe it is the difference between
> dependence and dependencies, or maybe interdependence.
>
> It is usual to write a unix Makefile top down. Starting with what is
> desired, then what is needed to produce that, eventually to the
> source files supplied. Unix make walks the tree, one direction, and
> then processes the files, as specified, the other direction.
script, of course. With CMake, however, I have a bunch of modules with
interdependencies that I don't even know (as long as they're not
circular, I'm not sure if that can be dealt with). As an example from my
own code, I can compile a bunch of files into libExample.a by simply doing
add_library(Example
file1.f90
file2.f90
file3.f90
....
fileN.f90
)
even though each file contains different modules with complex
interdependencies. CMake will simply build the dependency tree and I
don't even need to think about it.
> The Makefile supplied the first order dependencies, make has to find
> the second, third, etc., dependencies.
>
> The original MS make, on the other hand, did none of that. It was
> more like a conditional script. You had to put everything in the right
> order, or nothing much useful would happen at all. I used this before
> unix make, I believe with version 4.0 of the C compiler, about the
> same time as version 4.0 of the Fortran compiler.
>
> At that point, there wasn't a driver like unix cc, that calls both
> the compiler and linker. You had to compile by running the compiler,
> and link by running LINK. You had to specify the appropriate libraries,
> as there was no system to do that for you. Even the appropriate
> standard C library, with model dependence and floating point software
> or hardware versions.
Cheers
Paul
Ron Shepard
Jan 16, 2012, 12:55:34 PM1/16/12
to
In article <jf0p1c$5rc$1...@dont-email.me>,
the makefile. That tells other programmers how your code is
structured. It also tells you, six months later after you yourself
have forgotten the details, how your code is structured. So most of
us do not consider this aspect of the makefile dependencies a
liability of the makefile approach but rather an asset.
This was not so important with f77 codes. Programs could be built
by compiling the codes in whatever order was convenient, there were
no requirements imposed by the language. This changed with f90 with
the introduction of modules. At that point, something like the
dependencies described by the makefile became an essential part of
the program source code and program documentation.
Since you are just now starting to consider these options in your
program, you should be aware of a common programming practice. Most
compilers (maybe all of them now, I'm not sure) create an object
file and zero or more modules files when the process a file. Using
the de facto standard conventions, a *.f90 file is compiled to
produce a .o file and multiple .mod files. But with the make
utility, is is not convenient to specify the .mod files as
dependencies for subsequent targets. You really only want to
specify the source code relationships. So you will often see one .o
file that depends on other .o files in the makefile. There really
is no such dependency between these files. What is happening is
that the target .o files are acting as proxy dependencies for
however many .mod files are produced at the same time. "make" uses
the creating dates of the .o files to determine which .f90 files
need to be compiled, but it is really the .mod files that the
compiler needs, not the .mod files. This convention simplifies the
makefile structure, it basically eliminates all of the .mod files
from the target lists (except for things like "clean" PHONY
targets). The first time you see this you might be puzzled about
it, but as I say, this is a common convention among fortran
programmers, so you should be aware of it.
Here is a small example. Suppose compilation of a.f90 produces a.o,
a1.mod, a2.mod, and a3.mod, and suppose b.f90 requires those module
files to compile. Then instead of
b.o: a1.mod a2.mod a3.mod
a1.mod: a.f90
a2.mod: a.f90
a3.mod: a.f90
as the dependency, you would see simply
b.o: a.o
In this example, a.o is acting as a proxy for the three module files.
$.02 -Ron Shepard
> As an example from my
> own code, I can compile a bunch of files into libExample.a by simply doing
> add_library(Example
> file1.f90
> file2.f90
> file3.f90
> ....
> fileN.f90
> )
> even though each file contains different modules with complex
> interdependencies. CMake will simply build the dependency tree and I
> don't even need to think about it.
It is those interdependencies of the files that are documented by
> own code, I can compile a bunch of files into libExample.a by simply doing
> add_library(Example
> file1.f90
> file2.f90
> file3.f90
> ....
> fileN.f90
> )
> even though each file contains different modules with complex
> interdependencies. CMake will simply build the dependency tree and I
> don't even need to think about it.
the makefile. That tells other programmers how your code is
structured. It also tells you, six months later after you yourself
have forgotten the details, how your code is structured. So most of
us do not consider this aspect of the makefile dependencies a
liability of the makefile approach but rather an asset.
This was not so important with f77 codes. Programs could be built
by compiling the codes in whatever order was convenient, there were
no requirements imposed by the language. This changed with f90 with
the introduction of modules. At that point, something like the
dependencies described by the makefile became an essential part of
the program source code and program documentation.
Since you are just now starting to consider these options in your
program, you should be aware of a common programming practice. Most
compilers (maybe all of them now, I'm not sure) create an object
file and zero or more modules files when the process a file. Using
the de facto standard conventions, a *.f90 file is compiled to
produce a .o file and multiple .mod files. But with the make
utility, is is not convenient to specify the .mod files as
dependencies for subsequent targets. You really only want to
specify the source code relationships. So you will often see one .o
file that depends on other .o files in the makefile. There really
is no such dependency between these files. What is happening is
that the target .o files are acting as proxy dependencies for
however many .mod files are produced at the same time. "make" uses
the creating dates of the .o files to determine which .f90 files
need to be compiled, but it is really the .mod files that the
compiler needs, not the .mod files. This convention simplifies the
makefile structure, it basically eliminates all of the .mod files
from the target lists (except for things like "clean" PHONY
targets). The first time you see this you might be puzzled about
it, but as I say, this is a common convention among fortran
programmers, so you should be aware of it.
Here is a small example. Suppose compilation of a.f90 produces a.o,
a1.mod, a2.mod, and a3.mod, and suppose b.f90 requires those module
files to compile. Then instead of
b.o: a1.mod a2.mod a3.mod
a1.mod: a.f90
a2.mod: a.f90
a3.mod: a.f90
as the dependency, you would see simply
b.o: a.o
In this example, a.o is acting as a proxy for the three module files.
$.02 -Ron Shepard
Ian Harvey
Jan 16, 2012, 1:55:14 PM1/16/12
to
On 17/01/12 04:55, Ron Shepard wrote:
> In article<jf0p1c$5rc$1...@dont-email.me>,
> Paul Anton Letnes<paul.ant...@nospam.gmail.kthxbai.com>
> wrote:
>
>> As an example from my
>> own code, I can compile a bunch of files into libExample.a by simply doing
>> add_library(Example
>> file1.f90
>> file2.f90
>> file3.f90
>> ....
>> fileN.f90
>> )
>> even though each file contains different modules with complex
>> interdependencies. CMake will simply build the dependency tree and I
>> don't even need to think about it.
>
> It is those interdependencies of the files that are documented by
> the makefile. That tells other programmers how your code is
> structured. It also tells you, six months later after you yourself
> have forgotten the details, how your code is structured. So most of
> us do not consider this aspect of the makefile dependencies a
> liability of the makefile approach but rather an asset.
...
> In article<jf0p1c$5rc$1...@dont-email.me>,
> Paul Anton Letnes<paul.ant...@nospam.gmail.kthxbai.com>
> wrote:
>
>> As an example from my
>> own code, I can compile a bunch of files into libExample.a by simply doing
>> add_library(Example
>> file1.f90
>> file2.f90
>> file3.f90
>> ....
>> fileN.f90
>> )
>> even though each file contains different modules with complex
>> interdependencies. CMake will simply build the dependency tree and I
>> don't even need to think about it.
>
> It is those interdependencies of the files that are documented by
> the makefile. That tells other programmers how your code is
> structured. It also tells you, six months later after you yourself
> have forgotten the details, how your code is structured. So most of
> us do not consider this aspect of the makefile dependencies a
> liability of the makefile approach but rather an asset.
I'm with Paul on this one, strongly.
Managing dependencies is an unnecessary maintenance burden. Your code
already directly documents dependencies - it has USE statements. If you
want something better than that for humans to read then write a note in
a document or comment (preferably using a style that doesn't treat any
differences in horizontal whitespace characters as significant).
Far better tools (like CMake, and there are others) for running builds
are available today. make is a dinosaur - the only reason it is in use
is developer familiarity and existing-build-system inertia.
Ron Shepard
Jan 17, 2012, 1:52:28 AM1/17/12
to
In article <mo_Qq.1883$%E2....@viwinnwfe01.internal.bigpond.com>,
are not the same, and in fact there is not even a one-to-one
correspondence. That is what the make dependencies describe, which
files depend on which other files.
I agree with all of your disparaging comments about the make
utility. I've said worse things about make myself. But, that's the
common tool. That's just the fact.
$.02 -Ron Shepard
Ian Harvey <ian_h...@bigpond.com> wrote:
> Managing dependencies is an unnecessary maintenance burden. Your code
> already directly documents dependencies - it has USE statements.
Yes, but those are module dependencies, not file dependencies. They
> Managing dependencies is an unnecessary maintenance burden. Your code
> already directly documents dependencies - it has USE statements.
are not the same, and in fact there is not even a one-to-one
correspondence. That is what the make dependencies describe, which
files depend on which other files.
I agree with all of your disparaging comments about the make
utility. I've said worse things about make myself. But, that's the
common tool. That's just the fact.
$.02 -Ron Shepard
Paul Anton Letnes
Jan 17, 2012, 10:59:52 AM1/17/12
to
On 17.01.12 07:52, Ron Shepard wrote:
> In article<mo_Qq.1883$%E2....@viwinnwfe01.internal.bigpond.com>,
> Ian Harvey<ian_h...@bigpond.com> wrote:
>
>> Managing dependencies is an unnecessary maintenance burden. Your code
>> already directly documents dependencies - it has USE statements.
>
> Yes, but those are module dependencies, not file dependencies. They
> are not the same, and in fact there is not even a one-to-one
> correspondence. That is what the make dependencies describe, which
> files depend on which other files.
Sure, but why do you need to know those dependencies? Surely the module
> In article<mo_Qq.1883$%E2....@viwinnwfe01.internal.bigpond.com>,
> Ian Harvey<ian_h...@bigpond.com> wrote:
>
>> Managing dependencies is an unnecessary maintenance burden. Your code
>> already directly documents dependencies - it has USE statements.
>
> Yes, but those are module dependencies, not file dependencies. They
> are not the same, and in fact there is not even a one-to-one
> correspondence. That is what the make dependencies describe, which
> files depend on which other files.
dependencies are enough to understand the code? As long as your build
system handles the file dependencies, you don't care too much, do you?
> I agree with all of your disparaging comments about the make
> utility. I've said worse things about make myself. But, that's the
> common tool. That's just the fact.
makes some sense to use make. However, most people install non-standard
tools on their machines: editors, compilers, and build systems alike.
Very few of us use the default vi on unix or notepad in windows. Why
should we use make, just because it is common?
Paul
Richard Maine
Jan 17, 2012, 12:02:26 PM1/17/12
to
> Make is definitely common and ubiquitous, so for a small project, it
> makes some sense to use make. However, most people install non-standard
> tools on their machines: editors, compilers, and build systems alike.
> Very few of us use the default vi on unix or notepad in windows. Why
> should we use make, just because it is common?
For some of us, because our programs are used by other people. Yes, I
> makes some sense to use make. However, most people install non-standard
> tools on their machines: editors, compilers, and build systems alike.
> Very few of us use the default vi on unix or notepad in windows. Why
> should we use make, just because it is common?
could install lots of things on the systems I used. Sometimes I did. But
some of the people who used my programs were often in very different
situations. I needed a build method that had minimal requirements on
their systems. Sometimes it was a big deal to even get a Fortran
compiler on their system at all. Requiring them to install other tools
was not an option.
Yes, just because it was common was precisely the reason why I used
make. It had the best odds of being available on my users systems. Even
those odds weren't good enough in some cases. For a few of my programs,
I did a DOS batch script for a Windows install, as not all of my Windows
users had make available. A version of make came with some compilers,
but not all of them, and it depended on the compiler version. I didn't
try to do anything fancy at all in the DOS batch script. It was for
doing one-time builds - not for develpment. It just compiled all the
files in a fixed order.
I agree that make has lots of things wrong with it, as mentioned
elsethread. I quite disliked many things about it. But I used it anyway,
just because it was common.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Tim Prince
Jan 17, 2012, 6:22:32 PM1/17/12
to
there exist incompatible versions such as nmake and old SunOS and HPUX
make. I've had occasion to simply hand over a gmake.exe with a makefile
just so I didn't have to rewrite the makefile entirely between various
OS, so I don't consider the existence of nmake as a blocker. More
often, I simply check that it will build with cygwin make and mingw
gfortran, along with another compiler or 3. That way, our helpful
friends take responsibility for providing the GPL required sources and
documentation.
No one I deal with gets enough support from any system vendor that the
threat of withdrawal upon known use of gnu make is credible.
Some of my customers give me a script which drives make, an excellent
starting point, as it's not too difficult to pick and choose bits from
their script as necessary.
--
Tim Prince
stan
Jan 17, 2012, 9:40:48 PM1/17/12
to
Paul Anton Letnes wrote:
> On 17.01.12 07:52, Ron Shepard wrote:
<snip>
> On 17.01.12 07:52, Ron Shepard wrote:
>> I agree with all of your disparaging comments about the make
>> utility. I've said worse things about make myself. But, that's the
>> common tool. That's just the fact.
>
> Make is definitely common and ubiquitous, so for a small project, it
> makes some sense to use make. However, most people install non-standard
> tools on their machines: editors, compilers, and build systems alike.
> Very few of us use the default vi on unix or notepad in windows.
clones) or notepad. A frequent justification by notepad users is
similar to your argument against make - they aren't interested in
learning a complex application. The vi people pretty much just do it
to annoy the emacs types :)
> Why should we use make, just because it is common?
90% of the people reading could have provided assistance but asking
about MS specific batch files limits the possible help to a much
smaller fraction, as this thread proved.
For the record I add that to me the mod files, in particular, and
Fortran make interaction, in general, feel unnatural and
inelegant. Other languages feel much more natural and seem to fit
better.
Paul Anton Letnes
Jan 18, 2012, 1:59:49 AM1/18/12
to
On 18.01.12 03:40, stan wrote:
> Paul Anton Letnes wrote:
>> On 17.01.12 07:52, Ron Shepard wrote:
>
> <snip>
>
>>> I agree with all of your disparaging comments about the make
>>> utility. I've said worse things about make myself. But, that's the
>>> common tool. That's just the fact.
>>
>> Make is definitely common and ubiquitous, so for a small project, it
>> makes some sense to use make. However, most people install non-standard
>> tools on their machines: editors, compilers, and build systems alike.
>> Very few of us use the default vi on unix or notepad in windows.
>
> I'm pretty sure you would be shocked at the numbers who do use vi (and
> clones) or notepad. A frequent justification by notepad users is
> similar to your argument against make - they aren't interested in
> learning a complex application. The vi people pretty much just do it
> to annoy the emacs types :)
>
By all means: I use vi (technically, vim) because it's the most awesome
> Paul Anton Letnes wrote:
>> On 17.01.12 07:52, Ron Shepard wrote:
>
> <snip>
>
>>> I agree with all of your disparaging comments about the make
>>> utility. I've said worse things about make myself. But, that's the
>>> common tool. That's just the fact.
>>
>> Make is definitely common and ubiquitous, so for a small project, it
>> makes some sense to use make. However, most people install non-standard
>> tools on their machines: editors, compilers, and build systems alike.
>> Very few of us use the default vi on unix or notepad in windows.
>
> I'm pretty sure you would be shocked at the numbers who do use vi (and
> clones) or notepad. A frequent justification by notepad users is
> similar to your argument against make - they aren't interested in
> learning a complex application. The vi people pretty much just do it
> to annoy the emacs types :)
>
editor that I have worked with (so far). I don't know a lot of emacs
types so that doesn't matter either. But still - most people don't.
Paul
Paul Anton Letnes
Jan 18, 2012, 3:39:09 AM1/18/12
to
On 17.01.12 18:02, Richard Maine wrote:
> Paul Anton Letnes<paul.ant...@nospam.gmail.kthxbai.com> wrote:
>
>> Make is definitely common and ubiquitous, so for a small project, it
>> makes some sense to use make. However, most people install non-standard
>> tools on their machines: editors, compilers, and build systems alike.
>> Very few of us use the default vi on unix or notepad in windows. Why
>> should we use make, just because it is common?
>
> For some of us, because our programs are used by other people. Yes, I
> could install lots of things on the systems I used. Sometimes I did. But
> some of the people who used my programs were often in very different
> situations. I needed a build method that had minimal requirements on
> their systems. Sometimes it was a big deal to even get a Fortran
> compiler on their system at all. Requiring them to install other tools
> was not an option.
>
> Yes, just because it was common was precisely the reason why I used
> make. It had the best odds of being available on my users systems. Even
> those odds weren't good enough in some cases. For a few of my programs,
> I did a DOS batch script for a Windows install, as not all of my Windows
> users had make available. A version of make came with some compilers,
> but not all of them, and it depended on the compiler version. I didn't
> try to do anything fancy at all in the DOS batch script. It was for
> doing one-time builds - not for develpment. It just compiled all the
> files in a fixed order.
I am asking out of ignorance: why could you not compile your program for
> Paul Anton Letnes<paul.ant...@nospam.gmail.kthxbai.com> wrote:
>
>> Make is definitely common and ubiquitous, so for a small project, it
>> makes some sense to use make. However, most people install non-standard
>> tools on their machines: editors, compilers, and build systems alike.
>> Very few of us use the default vi on unix or notepad in windows. Why
>> should we use make, just because it is common?
>
> For some of us, because our programs are used by other people. Yes, I
> could install lots of things on the systems I used. Sometimes I did. But
> some of the people who used my programs were often in very different
> situations. I needed a build method that had minimal requirements on
> their systems. Sometimes it was a big deal to even get a Fortran
> compiler on their system at all. Requiring them to install other tools
> was not an option.
>
> Yes, just because it was common was precisely the reason why I used
> make. It had the best odds of being available on my users systems. Even
> those odds weren't good enough in some cases. For a few of my programs,
> I did a DOS batch script for a Windows install, as not all of my Windows
> users had make available. A version of make came with some compilers,
> but not all of them, and it depended on the compiler version. I didn't
> try to do anything fancy at all in the DOS batch script. It was for
> doing one-time builds - not for develpment. It just compiled all the
> files in a fixed order.
them and hand over the executable?
Paul
Richard Maine
Jan 18, 2012, 11:33:25 AM1/18/12
to
Paul Anton Letnes <paul.ant...@nospam.gmail.kthxbai.com> wrote:
> I am asking out of ignorance: why could you not compile your program for
> them and hand over the executable?
Several reasons.
> I am asking out of ignorance: why could you not compile your program for
> them and hand over the executable?
Biggest is that I had users on many different kinds of systems. I did
not have continual personal access to all the kinds of systems needed,
much less the exact system releases. For most systems, I had at least
managed to briefly get access at one point to verify that my code
worked. But that was likely to have been for some older version of both
my code and the system. I had a few users on systems that I had never
personally used. I recall one user on a SGI machine; I had used SGIs,
but not one of the same line.
Yes, that occasionally made support difficult. My software was developed
primarily for internal use. It was always free for outside users, so I
wasn't actually required to provide support, though I did so as best as
I could. Well, one of my programs was once converted into a Matlab
toolbox, but it wasn't me that did the conversion and I wasn't involved
in supporting it; I never even had a copy of Matlab that could run that
toolbox.
Oh yes, I guess that one of my programs also used to be in the COSMIC
system that NASA once used for software distribution, and people did pay
for that. That was a big bureaucratic fiasco. My biggest support issue
there was working around COSMIC's problems. I ended up sending most
people under-the-table copies of the progtam they had bought from
COSMIC. I wasn't "supposed" to do that. I forget the details (it was a
while ago, and I stopped submitting my programs to COSMIC afterwards),
but I think I recall things like people getting the programs from COSMIC
in the form of poorly photocopied and illegible paper listings; yuck.
Another reason is that sometimes customization of the software was
needed.
And for one case, a major part of the software wasn't a standalone
executable at all. It was a library of routines to be called by the
user's code. There were also a some utility programs with the library,
but the library was the main part of that distribution. I suppose I
could have distributed the linkable library, but that can get extra
picky about system versions.
Jim Cornwall
Jan 18, 2012, 6:37:18 PM1/18/12
to
Jim (yep, I use vi to do all my code editing...)
David Thompson
Feb 8, 2012, 6:00:29 AM2/8/12
to
On Sat, 14 Jan 2012 16:44:18 +0100, Luka Djigas <ldi...@at.gmail.com>
wrote:
> On Sat, 14 Jan 2012 14:23:59 +0000 (UTC), glen herrmannsfeldt
> <g...@ugcs.caltech.edu> wrote:
>
> >But if you want to, you can do something like:
> >
> >echo off
> >if exist %9.obj (
> >echo nine
> >) else if exist %8.obj (
> >echo eight
<snip>
and given your arguments are filenames, you can do:
set files=
for %%f in (%*) do set files=!files! %%~nf.obj
link %files%
Whether this qualifies as elegant deponent does not say.
wrote:
> On Sat, 14 Jan 2012 14:23:59 +0000 (UTC), glen herrmannsfeldt
> <g...@ugcs.caltech.edu> wrote:
>
> >But if you want to, you can do something like:
> >
> >echo off
> >if exist %9.obj (
> >echo nine
> >) else if exist %8.obj (
> >echo eight
> >) else echo none
> >
> >Replace each echo with the appropriate LINK command.
>
> Actually wrote it similar to that, in the end. Was hoping for a more
> elegant solution though.
>
If you configure DelayedCompletion on or go through CMD /V:ON,
> >
> >Replace each echo with the appropriate LINK command.
>
> Actually wrote it similar to that, in the end. Was hoping for a more
> elegant solution though.
>
and given your arguments are filenames, you can do:
set files=
for %%f in (%*) do set files=!files! %%~nf.obj
link %files%
Whether this qualifies as elegant deponent does not say.
0 new messages