On Monday, 19 June 2023 at 08:46:31 UTC, rempas wrote:
On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote:
target.obj: target.c include1.h include2.h cc.exe
cc target.c
and you either have to pray that you have kept the list of .h
files that are mentioned inside target.c and other .h files
referenced recursively from within these .h files etc. I
listed the compiler as a dependency too, and I should really
have a pseudo-target somehow that depends on the nature of the
command line because changing the command line affects the
generated code. If you have an automaking compiler that will
generate the list of .h files then that’s so, so much safer.
First of all, If we are talking about C files, D can import and
compile them so you don't even need a Makefile! Now, if you
need to compile C++ files and then either link or create a
library (and link with it from the D project), then you can
just run Dub in the end of the job in your make file! You can
then have a variable called `DUB_FLAGS` in your Makefile and
this is where the arguments that will be passed for the Dub
will be. Will this be good enough for you?
If I have sources to all the library routines, not libraries or
.obj files. I am simply completely ignorant about the D tools
including DUB, so off to do some reading. I’ve just been seeing
how good LDC and GDC are, and the answer is extremely, especially
LDC, which perhaps has a slight edge in code generation quality.
I haven’t looked at AAarch64 code yet, only AMD64. Very impressed
with all the work!
