List files are a feature of the assembler and not the front end. But I think this is something that would be useful for zcc so if someone else doesn't get around to it first, I will look at it in the next couple of days.
Would be even better if the current directory was set to the same directory as the .lst file that is processing, so file references are always relative to the .lst file the references are listed in.
I think we can grab the path from the list file's filename and then prepend that to all the files listed in the list file. That should do the job.
The downside is this would be different from z80asm's list files which currently work like zcc now with the current working directory being the root of all listed files but I think what you describe is what is expected by the user so I will have a look at changing the zcc version.
I am trying to include some asm files of bios routines I wrote into the startup_crt_o.m4/asm of my custom target (zalt).
The start of the path to the include file lies in the custom target directory (target/zalt).
Even the files I include in those bios files, must have the full relative path from that source location.
To me, that is counter-intuitive. The include-path should always start at the file the include is in...
It makes working with this harder than it should be...
I hope this is easy to fix although I think this one is in the assembler...?
[2c]
The assembler has the concept of include paths relative to which all include files are sought. This works like C include files where, eg, #include<..> searches relative to the system include directory and #include".." searches relative to the current working directory. In C, #include never searches relative to where the file containing #include is found. That's the way C source has always been organized and z80asm has copied that.
I'm not sure if changing this is desirable in the assembler or not.. it has implications for how source code is organized and would require changes in how the z88dk libraries' build scripts work, although that wouldn't stop us from making the change if it were preferable.
Even the files I include in those bios files, must have the full relative path from that source location.
To me, that is counter-intuitive. The include-path should always start at the file the include is in...
It makes working with this harder than it should be...
I hope this is easy to fix although I think this one is in the assembler...?
Includes relative to the source file's dir should be implemented in the July 9 build. This additional include path is the lowest priority one. Let us know if it works!
Just to let you know:
I try to include "./zalt_bios/bios.asm" in zalt_crt_0.m4/asm in the startup folder of my target (zalt).
It cannot find the file. When I make it "./startup/zalt_bios/bios.asm" it finds it but includes inside bios.asm fail...
Just to let you know:
I try to include "./zalt_bios/bios.asm" in zalt_crt_0.m4/asm in the startup folder of my target (zalt).
It cannot find the file. When I make it "./startup/zalt_bios/bios.asm" it finds it but includes inside bios.asm fail...
Folder structure: z88dk/libsrc/_DEVELOPMENT/target/zalt/startup/zalt_bios.
Yes this is a known issue with asm files. Any include problems with .m4, .h and .c files should be solved but .asm not yet because the assembler is not able to generate its output files in an arbitrary destination directory. With .m4, .h and .c files we use the original source files directly and then output the next stage file into the temp directory to keep temporary files away from the source files. We can't do that with .asm because the assembler can only output the resulting object file into the source directory which can cause problems with files being overwritten accidentally. What zcc is doing is first copying the .asm file to the temp dir and then assembling it there so that the object file is also in the temp directory. But moving the .asm file to a different location means relative include paths no longer work.
Surprisingly, no one has complained about this until you did We do have a fix in mind and that is adding the .asm file's original source directory to the include search path before assembling in the temp dir. Since you've found this issue, I'll see if I can find time in the next few days to fix it up.
I recently tested it with a hello world c program compiled with my zalt target and it works fine. I can get a log of the execution trail with address, mnemonics and cpu register values for each executed instruction and it also outputs waveforms for all electrical signals - which are also simulated.
alvin wrote:Surprisingly, no one has complained about this until you did We do have a fix in mind and that is adding the .asm file's original source directory to the include search path before assembling in the temp dir. Since you've found this issue, I'll see if I can find time in the next few days to fix it up.
I'm not complaining or in a hurry
I just don't like coupling my code to file locations.
alvin wrote:Surprisingly, no one has complained about this until you did We do have a fix in mind and that is adding the .asm file's original source directory to the include search path before assembling in the temp dir. Since you've found this issue, I'll see if I can find time in the next few days to fix it up.
I applied the fix tonight which will make it available in the Dec 27 build. Let us know if the problem is resolved when you get a chance.
We do have a fix in mind and that is adding the .asm file's original source directory to the include search path before assembling in the temp dir. Since you've found this issue, I'll see if I can find time in the next few days to fix it up.