How does D’s ‘import’ work?

[Cecil Ward]

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!