Compile directory, work directory and relative paths

[phx]

In the past I made multiple changes in vasm concerning locating files via compile- and work-directory. Still I have the impression that it's not quite right.

I think we agree on the following definition:

• Work directory: The system's (usually the shell's) current work directory, when starting the assembler. Not the directory where the assembler binary is located.
• Compile directory: The directory where the main input source is located.

When using relative paths to include files, would you expect that path to be appended to the work directory first, then to the compile directory, if it didn't exist? Or the other way around?

[paraj]

GCC's (implementation defined) way of handling quoted include paths matches my (perhaps learned) intuition.
I.e. if the work directory is "PROJECT:", I run "vasm -Iinc src/foo/bar.S" and "bar.S" includes "lib/lib.i", I would expect it to try PROJECT:src/foo/lib/lib.i first, then PROJECT:inc/lib/lib.i, and give up if neither file exist.
That's without considering anything else though. If say VBCC's preprocessor or a prominent legacy assembler does something noticeably different then that should certainly be considered.

[Auscoder]

I would prefer compile then work directory, nothing else considered ??

[alkis]

I would also prefer compile directory first.

[phx]

Thanks for the input!

It's interesting that most suggest compile-dir first, and paraj even wants to ignore the work-dir. For a comparison I just checked Devpac, BAsm and PhxAss, and all of them ignore the compile-dir!

Seems that the concept of a compile directory doesn't exist for assemblers (68k-assemblers, Amiga-assemblers)? Although my personal preference would also be to use the compile-dir with high priority.

Originally Posted by paraj

GCC's (implementation defined) way of handling quoted include paths matches my (perhaps learned) intuition.

Indeed, most likely I had the usual compiler behaviour in mind, when implementing compile-dir paths. But does it make sense for an assembler?

I.e. if the work directory is "PROJECT:", I run "vasm -Iinc src/foo/bar.S" and "bar.S" includes "lib/lib.i", I would expect it to try PROJECT:src/foo/lib/lib.i first, then PROJECT:inc/lib/lib.i, and give up if neither file exist.

Hmm. So PROJECT:lib/lib.i would be ignored. Could make sense, when the main source is not located in the work directory. But I'm not sure.

That's without considering anything else though. If say VBCC's preprocessor or a prominent legacy assembler does something noticeably different then that should certainly be considered.

Again, compilers have nothing to do with it. Important is only what you would expect from an assembler.

The most prominent legacy assembler would be Devpac, and it ignores the compile-dir. But as most of us (including myself) like compile-dirs, it may be a compromise to search the work-dir first, to avoid bad surprises with legacy source texts?

Anyway, currently vasm's search strategy seems broken, because it locates a file without a path in the compile-dir first, but looks for relative include-paths in the work-dir first...

[meynaf]

Let's say you have file foo.s including bar.i and now you want to create a temporary copy of bar.i to perform some tests.
So you put that copy somewhere, assemble your source from this new place (= new work-dir)... and discover your changes are ignored because compile-dir, which contains original version, is used first. Argh.
It's not hard to fix - just rename the original file or duplicate the whole tree - but nevertheless.

As current 68k assemblers seem to ignore compile-dir and because of the above example, i'd choose work-dir first.

[a/b]

Well, in c/c++ you can include as "" or <>, giving you a choice (and on top of that you can use -I on cmd line).
In asms, the ones I've been using more or less for the last 30 years (from seka to asm-one derivatives), base dir is the source dir (or an optionally configurable dir), and if you want to look elsewhere you can use INCDIR.
Now on the other hand, devpac style asms (non-interactive)... They could benefit from a -I parameter, so you could keep your sources independent that way.
And finally, when it comes to conflicts I'd prefer source dir first so I could overrider whichever file is or potentially could cause problems.

[a/b]

Originally Posted by meynaf

So you put that copy somewhere, assemble your source from this new place (= new work-dir)... and discover your changes are ignored because compile-dir, which contains original version, is used first. Argh.

Yep...

[phx]

I tend to agree with Meynaf, and work-dir-first could solve most of the problems and keeps compatibility, while still finding files in the compile-dir with lower priority.

Although a current work directory, which accidently has the same include file name as in your compile directory, may also be the reason for puzzling bugs.

Originally Posted by a/b

And finally, when it comes to conflicts I'd prefer source dir first so I could overrider whichever file is or potentially could cause problems.

With "source dir first" you mean compile directory?

Another question would be if relative include paths should actually be searched in the compile-dir at all, or just in the work-dir. Now I think this is also what paraj wanted to indicate in his example.

[meynaf]

At worse you can always make the behaviour user-configurable.

[a/b]

Originally Posted by phx

With "source dir first" you mean compile directory?

Yes.

[paraj]

FWIW I don't have a strong opinion and was just offering my 2 cents. The reason I mentioned VBCC, even though you only asked about VASM, is precisely because of the scenario brought up by meynaf. If you're working a on mixed ASM/C project and it behaves differently for assembly and C include files that could be confusing.

Also don't know if you're just considering m68k or other supported archs (which I don't care much about ). Either way it probably I'd probably prefer whatever is most compatible with existing code, as I can always adapt new code (which when written in ASM, isn't going to rely on these things).

[phx]

Thanks for the input! I understand it is important to look into the work-dir first. I also added the new option

-nocompdir

to ignore the compile-dir completely.

Doing further tests, I noticed that Devpac is one of the few classic assemblers which supports a compile-dir, but after work-dir and not for relative include paths, which are always work-dir based.

Some assemblers (e.g. basm) will search in

incdir

paths before the work-dir. I chose to search work-dir, then compile-dir, first, following Devpac as reference.

[Auscoder]

I have compile dir and work dir as the same as I deploy a custom vasm build to my work dir. I also have any dependencies within a subdir here. I like to keep all my project deps together per project. If I were not doing that ie with seperate dirs I would expect work dir first when an include path has not been set.