The latest unsuccessful build is due to incorrect include search path order.
dstar is being built in two ways with two identically named source files in two different directories.
In the Makefile directory there is:
dstar.c dstar.h
In the directory above there is:
dstar.c dstar.h
In the Markefile dir the build command is:
zcc +zx -vn ../dstar.c -I.. -Dspritesize=16 -DSOUND -create-app -odstar.bin
The first problem is zcc puts the user -I.. at the end of the zcpp invocation so that -I. (supplied by cfg file) appears before it. This means the local dstar.h is used to compile with instead of ../dstar.h because . is searched before .. The local dstar.h is not the same and causes a build error.
So I tried fixing that by having zcc put -I search paths from the compile line in front of everything else in the zcpp invocation. That should have fixed the problem but it didn't. It turns out zcpp itself will search the . directory first if the include file is in quotations. So despite .. appearing first in the search path list, zcpp looks in . first and finds the wrong dstar.h, causing an error again. Here the bug is the current working directory should be .. when the source file is ../dstar.c. zcpp should be modifying its current working directory according to the location of the source file it's processing. And now I think I understand why .c files were not copied -- after copying the .c file, the path information is lost. So either zcpp has to be given the information or I have to fix the .c.m4 problem a different way.
Anyway this is the way I think it should be for include search paths:
* user supplied include search paths appear first in zcpp invocation
* system supplied include search paths appear last
* remove -I. from all cfg files (we rely on zcpp to search . when includes use quotations, doublecheck with zsdcpp)
(if the user supplies his own "stdio.h" it will be used in preference to the system's <stdio.h>)
For library search paths:
* user supplied search paths appear first
* system search paths appear second (user can replace system libraries of the same name)
* -L. is added to the end of the user search list
* linked libraries ("-lname" or "-lm", etc) appear after all library search paths are listed so that the linker has a complete set of ordered search paths in hand. system supplied link libraries appear last. This way the user can replace system functions with his own implementation.
Any comments? For the time being I disabled the some of the dstar builds so hopefully tonight's build will succeed. Maybe I should have let it fail again.
------------------------------------------------------------------------------
[z88dk-dev] Incorrect include search path order and library path ord
Alvin,
The priority you suggest seems ideal to me, at a first glance.
Being able to overlap the default libraries with user supplied ones was a great achievement, and it is worth to get it stable now, so I agree we need to take care of it.
Fixing the nightly build with a workaround is not a big problem, since it already did the job to show the problem.
------------------------------------------------------------------------------
The priority you suggest seems ideal to me, at a first glance.
Being able to overlap the default libraries with user supplied ones was a great achievement, and it is worth to get it stable now, so I agree we need to take care of it.
Fixing the nightly build with a workaround is not a big problem, since it already did the job to show the problem.
------------------------------------------------------------------------------
Ok I went ahead with the changes and I think everything is correct now. If you have a chance, maybe try a few tests.The priority you suggest seems ideal to me, at a first glance.
Being able to overlap the default libraries with user supplied ones was a great achievement, and it is worth to get it stable now, so I agree we need to take
------------------------------------------------------------------------------