I've got an option in HLA that writes all temporary output files to a user-specified subdirectory (e.g., something like "tmp" in the current directory) to avoid clutter when assembling lots of files. A typical HLA output file for FASM begins with code like the following:



In particular, note that the "include" statements specify an include file that appears in the same subdirectory as the ".asm" file being assembled. The problem occurs when you run FASM with a different directory as the default directory, e.g., suppose you have the following:



Unfortunately, FASM looks in the *current* directory rather than the directory containing the "t.asm" file when searching for the include files. As a result, FASM fails to find those include files that are in the same directory as the .asm file and assembly stops.

I'd recommend that FASM do the following when opening an include file:

1. First, search in the same directory as the .asm file being assembled, if not found, then:

2. Second, search in the current directory for the include file. If not found, then:

3. Third, search in a directory specified by an environment variable. If not found,

4. Fourth, report an error.

You could probably switch (1) and (2), but I suspect that it's more intuitive to first look in the same directory containing the .asm file.

Note that MASM, Gas, and other assemblers do this (i.e., they handle HLA's output without any problem).

Yes, I could specially modify HLA's output to put full paths into the strings, but then the assembly files couldn't be moved around in the directory structure. As I said, the behavior above is roughly what other assemblers are doing, so it might not be a bad approach for FASM.
Cheers,
Randy Hyde


where the file to be assembled is sitting in the tmp directory within the current directory.

Well, this is the "bad" feature that is kept mainly for backward compatibility. Some solutions were discussed here: http://board.flatassembler.net/topic.php?t=583

Anyway your suggestion may be a good idea - I think it would keep the enough backward compatibility while providing simple solution to this problem.

Yeah, about the only problem I can imagine is if you've got two header files with the same name, one in the same directory at "t.asm" and one in the current directory. Of course, anyone writing such code pretty must deserves the ambiguity that arises!

Still, I must say that when I added this feature to HLA, I was careful to look at what other assemblers (in particular, MASM & TASM) did, and what they did seemed quite reasonable so I went with that (which I described in my original post).

As for the thread you mentioned, I gave it a quick once-over. I think the rules I laid out would work fine for what the OP wanted. That is, first look in the directory containing the file with the "include" directive, then look in the "current" directory. It's easy to imagine a situation where you have one file including another from a different directory, which includes another file from a different directory, etc., etc., and you wind up with a chain of possible locations. But if such a source code organization fouls up an assembly, that should be a pretty good clue to the user that they need to reorganize their directory structure for the project.

You could go crazy with all the possibilities, but I think that the 'four step' algorithm I gave earlier will handle 99.9% of the cases.
Cheers,
Randy Hyde

nice idea

ambiguity problem can be solved by always looking at all directories and if there are more files with that name just report error.