this is useful when one is using several dependencies as git submodules - i. e. in their own directories.
these submodules may want to come with own makefiles, that will build and create symbol and object files in their own build directories.
we still have MODULES environment variable which gets parsed by voc, and voc is able to find symbol files in the MODULES search path.
However, generated gcc string doesn't take MODULES in to consideration.
thus, if we have module M0 in directory "dep0" and module M1 in directory "src", we build dependency in dep0 directory, then build M1, and voc is able to find M0.sym and generate c files.
Later, gcc string doesn't know about it.
M1.Mod Compiling M1. Main program. 323 chars.
M1.c:9:10: fatal error: M0.h: No such file or directory
9 | #include "M0.h"
| ^~~~~~
compilation terminated.
C compile and link: gcc -fPIC -g -I "/opt/voc/2/include" M1.c -o M1 -L"/opt/voc/lib" -lvoc-O2
-- failed: status 0, exitcode 1.
Terminated by Halt(1).
I think it would be useful to add -I and -L flags for gcc in order to make projects with such dependencies built easier. By the way, voc-1.0 version was able to do so.
this is useful when one is using several dependencies as git submodules - i. e. in their own directories.
these submodules may want to come with own makefiles, that will build and create symbol and object files in their own build directories.
we still have MODULES environment variable which gets parsed by voc, and voc is able to find symbol files in the MODULES search path.
However, generated gcc string doesn't take MODULES in to consideration.
thus, if we have module M0 in directory "dep0" and module M1 in directory "src", we build dependency in dep0 directory, then build M1, and voc is able to find M0.sym and generate c files.
Later, gcc string doesn't know about it.
I think it would be useful to add -I and -L flags for gcc in order to make projects with such dependencies built easier. By the way, voc-1.0 version was able to do so.