On Saturday, 3 June 2023 at 09:04:35 UTC, Dom DiSc wrote:
>
> You can replace your whole makefile by calling the compiler with -I (not always, but if you don't do funny things in your makefile).

That would be `-i`.

> - This ability of the D compiler was just recently discovered (after -I was implemented for other reasons), but it relies on the fact that we have imports.

Jonathan Marler implemented it in 2017 after a discussion in the forums.

https://github.com/dlang/dmd/pull/7099

On Friday, 2 June 2023 at 12:07:09 UTC, rempas wrote:
> On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote:
>>
>> I have another question if I may, what do we do about getting makefiles right given that we have imports ?
>
> What do you mean with that? Give some more info please!

I was thinking about the situation in C where I have a rule in a make file that lists the .h files as well as the .c all as dependencies in creating an object file.

On 6/7/23 21:17, Cecil Ward wrote:

> I was thinking about the situation in C where I have a rule in a make
> file that lists the .h files as well as the .c all as dependencies in
> creating an object file.

dmd's -makedeps command line switch should be helpful there. (I did not use it.)

Ali

On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward wrote:
> Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process.

I do wonder why no-one have linked the [Modules and libraries](https://ddili.org/ders/d.en/modules.html) section in the [Programming in D](https://ddili.org/ders/d.en/index.html) book! The book is outdated in some things (and this isn't with logic, I have found one of these cases myself) but for most things, it will be ok!

On Thursday, 8 June 2023 at 04:17:20 UTC, Cecil Ward wrote:
> I was thinking about the situation in C where I have a rule in a make file that lists the .h files as well as the .c all as dependencies in creating an object file.

I don't think I'm aware of what you mean with "lists .h and .c files". Could you provide a small makefile that does that so I can run and examine?

On Sunday, 18 June 2023 at 17:34:51 UTC, rempas wrote:
> On Thursday, 8 June 2023 at 04:17:20 UTC, Cecil Ward wrote:
>> I was thinking about the situation in C where I have a rule in a make file that lists the .h files as well as the .c all as dependencies in creating an object file.
>
> I don't think I'm aware of what you mean with "lists .h and .c files". Could you provide a small makefile that does that so I can run and examine?

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.

On Thursday, 8 June 2023 at 05:11:04 UTC, Ali Çehreli wrote:
> On 6/7/23 21:17, Cecil Ward wrote:
>
> > I was thinking about the situation in C where I have a rule
> in a make
> > file that lists the .h files as well as the .c all as
> dependencies in
> > creating an object file.
>
> dmd's -makedeps command line switch should be helpful there. (I did not use it.)
>
> Ali

I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.)

On Sunday, 18 June 2023 at 20:24:10 UTC, Cecil Ward wrote:
> On Thursday, 8 June 2023 at 05:11:04 UTC, Ali Çehreli wrote:
>>
>> dmd's -makedeps command line switch should be helpful there. (I did not use it.)
>>
>> Ali
>
> I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.)

LDC has the same feature with its --makedeps flag.

On Sunday, June 18, 2023 2:24:10 PM MDT Cecil Ward via Digitalmars-d-learn wrote:
> I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.)

In general, dmd is fantastic for its fast compilation speed. So, it works really well for developing whatever software you're working on (whereas ldc and gdc are typically going to be slower at compiling). And depending on what you're doing, the code is plenty fast. However, if you want to maximize the efficiency of your code, then you definitely want to be building the binaries that you actually use or release with ldc or gdc.

- Jonathan M Davis

On Sun, Jun 18, 2023 at 03:51:14PM -0600, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Sunday, June 18, 2023 2:24:10 PM MDT Cecil Ward via Digitalmars-d-learn wrote:
> > I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.)

My experience with D for the past decade or so has consistently shown that executables produced by LDC or GDC generally run about 40% faster than those produced by DMD. Especially with CPU-intensive computations. This is just the hard fact.

Of course, for some applications like shell-script replacements (which, incidentally, D is really good at -- once your script passes the level of complexity beyond which writing a shell script just becomes unmanageable), the difference doesn't really matter, and I'd use DMD just for faster compile times.

The one thing the DMD backend is really good at, is compiling stuff *really* fast. LDC has been catching up in this department, but currently DMD still wins the fast compilation time race, by quite a lot. So it's very useful for fast turnaround when you're coding.  But for release builds, LDC and GDC are your ticket.


> In general, dmd is fantastic for its fast compilation speed. So, it works really well for developing whatever software you're working on (whereas ldc and gdc are typically going to be slower at compiling). And depending on what you're doing, the code is plenty fast. However, if you want to maximize the efficiency of your code, then you definitely want to be building the binaries that you actually use or release with ldc or gdc.
[...]

Yeah, LDC/GDC are really good at producing optimized executables, but they do take a long time to do it. (Probably 'cos it's a hard problem!) So for development -- DMD.  For final release build -- GDC/LDC.


T

-- 
If it tastes good, it's probably bad for you.