I have been contemplating how to deal with the
issue of the temporary files that HLA produces.
A "Quick & Dirty" solution, of course, is to just add
a command line parameter (e.g. "-t:<path>") to
specify where HLA should put the temporary files.
An environment variable (e.g., HLATEMP) could also
provide a default location for these things.
However, it occurs to me that 95% of the time,
nobody really wants these things laying around
after a compile anyway. So I'm wondering if it
wouldn't be a better idea to simply delete the
temporary files once compilation is complete.
Of course, if you want the ".asm" and ".inc" files,
the -s (or -st, -sg, -sm, and soon, -sf) command
line options would leave them. Doing this makes
so much sense that it's probably the way I will
go unless some people out there scream and holler.
I'm assuming that, since compile to assembly source
is a relatively rare thing, that there would be no need
to put the temporary files in some other directory
if I clean up after myself (and if you specify one of the
source output options, getting the source in the current
directory isn't too bad).
It wouldn't be too hard to change the -s options to
something like "-s:<path>" but before I bother, I should
probably see if the solution above wouldn't satisfy everyone.
There is also the question of where to put the .obj file that
assembling the source file produces. There's probably a need
to specify the destination of the .obj file independently of the
assembly source files (since someone is probably more likely
to want to keep the .OBJ files around, and probably not in a
catch-all "temp" directory).
Any and all comments are welcome on this one.
Randy Hyde
issue of the temporary files that HLA produces.
A "Quick & Dirty" solution, of course, is to just add
a command line parameter (e.g. "-t:<path>") to
specify where HLA should put the temporary files.
An environment variable (e.g., HLATEMP) could also
provide a default location for these things.
However, it occurs to me that 95% of the time,
nobody really wants these things laying around
after a compile anyway. So I'm wondering if it
wouldn't be a better idea to simply delete the
temporary files once compilation is complete.
Of course, if you want the ".asm" and ".inc" files,
the -s (or -st, -sg, -sm, and soon, -sf) command
line options would leave them. Doing this makes
so much sense that it's probably the way I will
go unless some people out there scream and holler.
I'm assuming that, since compile to assembly source
is a relatively rare thing, that there would be no need
to put the temporary files in some other directory
if I clean up after myself (and if you specify one of the
source output options, getting the source in the current
directory isn't too bad).
It wouldn't be too hard to change the -s options to
something like "-s:<path>" but before I bother, I should
probably see if the solution above wouldn't satisfy everyone.
There is also the question of where to put the .obj file that
assembling the source file produces. There's probably a need
to specify the destination of the .obj file independently of the
assembly source files (since someone is probably more likely
to want to keep the .OBJ files around, and probably not in a
catch-all "temp" directory).
Any and all comments are welcome on this one.
Randy Hyde
Okay, having looked a little closer...
First, you cannot specify a single object file output name
from the HLA command line. The reason is simple, HLA
allows you to specify multiple .HLA files on a single command
line. In theory, I *could* allow the specification of an obj
output name for each .HLA name (or each .ASM or each
.RES or each .RC, etc.) on the command line, but this is
starting to get crazy.
Here's what I am currently implementing:
If you specify a "source" output command line parameter
(-s, -st, -sm, -sf, -sg) then HLA will not clean up after
itself, all the .asm, .inc, and .link files will be present
after the compilation.
If you specify the -c (compile and assemble to OBJ file) then
HLA will delete the .asm and .inc files after assembling the
file (note that if there is a bug in HLA's code generator and
the assembler generates an error, the .asm and .inc files will
not be deleted). Note that when using the -c option, HLA
will not clean up the .link file (since the linker still needs this
file).
HLA will delete the .link file after successfully linking the file
to produce an executable.
In addition, I'm adding the following two command line parameters
to HLA.EXE:
-p:<path>
-obj:<path>
Also, HLA will recognize a new environment variable, HLATEMP.
The -p option specifies a path to some directory where HLA will
place all temporary files (.asm, .inc, and .link). The HLATEMP environment
variable will also specify this path; note, however, that the -p option
overrides the environment variable. If neither option is specified, then
HLA puts all temporary files in the current directory.
-obj:<path> specifies where HLA will store the output object files
from the current assembly. There is no environment variable for this
item. The default is the current directory.
I'm also fixing up the problem that occurs if you try something like this
hla somedir\src.hla
(it places the obj file in the current directory and then tries to link in
the "somedir" directory, and fails to find the src.obj file).
Hopefully, this will resolve the issues people have had with
HLA's inability to work with files across multiple directories.
Randy Hyde
First, you cannot specify a single object file output name
from the HLA command line. The reason is simple, HLA
allows you to specify multiple .HLA files on a single command
line. In theory, I *could* allow the specification of an obj
output name for each .HLA name (or each .ASM or each
.RES or each .RC, etc.) on the command line, but this is
starting to get crazy.
Here's what I am currently implementing:
If you specify a "source" output command line parameter
(-s, -st, -sm, -sf, -sg) then HLA will not clean up after
itself, all the .asm, .inc, and .link files will be present
after the compilation.
If you specify the -c (compile and assemble to OBJ file) then
HLA will delete the .asm and .inc files after assembling the
file (note that if there is a bug in HLA's code generator and
the assembler generates an error, the .asm and .inc files will
not be deleted). Note that when using the -c option, HLA
will not clean up the .link file (since the linker still needs this
file).
HLA will delete the .link file after successfully linking the file
to produce an executable.
In addition, I'm adding the following two command line parameters
to HLA.EXE:
-p:<path>
-obj:<path>
Also, HLA will recognize a new environment variable, HLATEMP.
The -p option specifies a path to some directory where HLA will
place all temporary files (.asm, .inc, and .link). The HLATEMP environment
variable will also specify this path; note, however, that the -p option
overrides the environment variable. If neither option is specified, then
HLA puts all temporary files in the current directory.
-obj:<path> specifies where HLA will store the output object files
from the current assembly. There is no environment variable for this
item. The default is the current directory.
I'm also fixing up the problem that occurs if you try something like this
hla somedir\src.hla
(it places the obj file in the current directory and then tries to link in
the "somedir" directory, and fails to find the src.obj file).
Hopefully, this will resolve the issues people have had with
HLA's inability to work with files across multiple directories.
Randy Hyde
You are doing such a good job talking to yourself that I decided to keep out of it.
Actually you decided to do what I would have liked to suggest (path -p, and environment variable), but didn't because I have no idea how much work is involved.
Best,
Scott
Actually you decided to do what I would have liked to suggest (path -p, and environment variable), but didn't because I have no idea how much work is involved.
Best,
Scott
You are doing such a good job talking to yourself that I decided to keep out of it.
Actually you decided to do what I would have liked to suggest (path -p, and environment variable), but didn't because I have no idea how much work is involved.
Best,
Scott
Actually, the truth is that these simple changes are *almost* easy enough
that anyone (well, any C programmer) would be able to do it themselves.
Most of the work takes place in HLA.C, which is a "shell" program that
runs HLAPARSE.EXE (the real HLA compiler), ML/FASM/GAS/whatever,
the resource compiler, and the linker.
I am passing the -p and -obj parameters on to HLAPARSE, but I suspect
that I could have avoided this with some "chdir" trickery.
Thus far, I've fixed the problem with "hla somedir\somefile.hla" (this
one was easy) and now I'm about to start working on HLAPARSE
to handle the -p and -obj parameters I'm passing on down from HLA.EXE.
Randy Hyde
Randy,
I usually try and keep all the stuff for one exe in one place so I wonder if you could write the temp files in the directory that the build ias done from and clean out what you think is worth removing after the build.
I reliably ditch all of the OBJ files after I have built a library as there is no point in keeping them. In your case when an intermediate asm file is produced, perhaps just keep that and ditch the rest. It is at least tidy.
It certainly could be done with a TEMP veriable but many of the younger programmers did not grow up with DOS style environments so it may be a little strange to some of them.
Regards,
hutch@movsd.com
I usually try and keep all the stuff for one exe in one place so I wonder if you could write the temp files in the directory that the build ias done from and clean out what you think is worth removing after the build.
I reliably ditch all of the OBJ files after I have built a library as there is no point in keeping them. In your case when an intermediate asm file is produced, perhaps just keep that and ditch the rest. It is at least tidy.
It certainly could be done with a TEMP veriable but many of the younger programmers did not grow up with DOS style environments so it may be a little strange to some of them.
Regards,
hutch@movsd.com
It certainly could be done with a TEMP veriable but many of the younger programmers did not grow up with DOS style environments so it may be a little strange to some of them.
Ahh, the generation gap. :)
Randy,
I usually try and keep all the stuff for one exe in one place so I wonder if you could write the temp files in the directory that the build ias done from and clean out what you think is worth removing after the build.
I reliably ditch all of the OBJ files after I have built a library as there is no point in keeping them. In your case when an intermediate asm file is produced, perhaps just keep that and ditch the rest. It is at least tidy.
It certainly could be done with a TEMP veriable but many of the younger programmers did not grow up with DOS style environments so it may be a little strange to some of them.
Regards,
hutch@movsd.com
Definitely the way I'm headed right now is to allow
the OBJ and ASM/INC/LINK files to be put into separate (user-specifiable)
directories during compilation. That's fairly easy.
I haven't *completely* thought through the issue of
deleting the ASM/INC/LINK files after a successful assembly yet.
On the surface, it sounds okay; but I'm sure that as I dig a little
deeper into this, I discover some problems with the approach.
Deleting OBJ files after a successful link operation has already
reared its ugly head as a problem -- there are too many MAKEFILEs
in this world that check the need to rebuild the system based on
the date/time of the obj files. This realization has led me to be
wary of file deletion, in general, by the compiler.
Of course, placing the files in a user-specified directory (local
or global depending on command line parameters or environment
variables) solves much of the problem. The global solution (e.g.,
using an environment variable) has a few problems (what happens
if two different projects produce some temporary files that have the
same name? If they wind up going into the same global directory this
could be a problem).
When I first attacked this problem, it seemed trivial.
Like all trivial problems, it's starting to blow up on me :-(
Randy Hyde
Randy,
I think as long as you seperate app specific files from shared files, you should not have any problems. Anything app specific is probably best left in the local app directory where shared files should not be subject to modification by an app.
Libraries make this simple but where you want to seperate between a library of source code that is available for an app and the local files for an app, it should be no problem to do you own cleanup of local application files after a build. Perhaps an option to allow the user to leave what they need, the asm file for example and clean out what they don't want.
Regards,
hutch@movsd.com
I think as long as you seperate app specific files from shared files, you should not have any problems. Anything app specific is probably best left in the local app directory where shared files should not be subject to modification by an app.
Libraries make this simple but where you want to seperate between a library of source code that is available for an app and the local files for an app, it should be no problem to do you own cleanup of local application files after a build. Perhaps an option to allow the user to leave what they need, the asm file for example and clean out what they don't want.
Regards,
hutch@movsd.com
You can always create a subdirectory to hold temporary files. Make it local to the source directory.
This is the way the IDE for VC works.
Source file directory: ......\project
Object and exe files for debug version: .......\project\Debug
Object and exe files for release version: ......\project\Release
It looks fairly straightforward to me. This has the advantage that it separates the two kinds of ASM files -- those written or imported by a programmer, and those generated by a compiler -- while keeping everything local.
This is the way the IDE for VC works.
Source file directory: ......\project
Object and exe files for debug version: .......\project\Debug
Object and exe files for release version: ......\project\Release
It looks fairly straightforward to me. This has the advantage that it separates the two kinds of ASM files -- those written or imported by a programmer, and those generated by a compiler -- while keeping everything local.
Well, thus far I've gotten the
"temporary files" (.asm, .inc, .link) directory and the
"object files" (.obj, .res) directory options working in HLA v1.43.
I'm thinking about holding off on the "clean-up" option.
After all, most people just want the compiler-produced
files out of the way so they don't clutter up the project directory.
Any clean-up that the programmer wants done during a build is
easy enough to put into a makefile or an IDE (using one of the
existing, programmable, editors).
I'll probably revisit the issue of clean up later.
The comments about creating the directory got me thinking though,
it would be nice if HLA created the temps automatically if one wasn't
specified by the user. OTOH, that's going to break a lot of makefiles
(mine, if no one else's :-) ).
Randy Hyde
"temporary files" (.asm, .inc, .link) directory and the
"object files" (.obj, .res) directory options working in HLA v1.43.
I'm thinking about holding off on the "clean-up" option.
After all, most people just want the compiler-produced
files out of the way so they don't clutter up the project directory.
Any clean-up that the programmer wants done during a build is
easy enough to put into a makefile or an IDE (using one of the
existing, programmable, editors).
I'll probably revisit the issue of clean up later.
The comments about creating the directory got me thinking though,
it would be nice if HLA created the temps automatically if one wasn't
specified by the user. OTOH, that's going to break a lot of makefiles
(mine, if no one else's :-) ).
Randy Hyde