I ran into this bug a few days ago.

DMD, when specifying -od (output directory), -of (output file) and *only* when in -lib mode, treats the output file path as relative to the output directory path. Ie. -odfoo -oflibbar.a results in foo/libbar.a as opposed to ./libbar.a. This is in contradiction to every other mode (-shared, binary output, object output) and every other D compiler (ldc, gdc).

This issue was raised four years ago. At the time, Walter said he was not fixing it in order to avoid breaking compatibility with existing build setups: see https://github.com/dlang/dmd/pull/4753 .

People who are using build tools that call dmd: would you rather this be fixed, and have to update your code, or leave it in?

(Me, I want it fixed. It's a really annoying trap for all the people who are building with dmd but aren't using -od yet, which I was among until a few days ago.)

On Monday, 12 August 2019 at 05:59:53 UTC, FeepingCreature wrote:
> I ran into this bug a few days ago.
>
> DMD, when specifying -od (output directory), -of (output file) and *only* when in -lib mode, treats the output file path as relative to the output directory path. Ie. -odfoo -oflibbar.a results in foo/libbar.a as opposed to ./libbar.a. This is in contradiction to every other mode (-shared, binary output, object output) and every other D compiler (ldc, gdc).
>
> [...]

It's a bug and should be fixed.
I would be surprised if it actually breaks a build tool. They (e.g. dub) just use -of.

On Monday, 12 August 2019 at 05:59:53 UTC, FeepingCreature wrote:
> This is in contradiction to every other mode (-shared, binary output, object output) and every other D compiler (ldc, gdc).

I think I added compatibility for this quirky behavior in the ldmd2 driver (which is supposed to be DMD-compatible).

On Monday, 12 August 2019 at 05:59:53 UTC, FeepingCreature wrote:
> I ran into this bug a few days ago.
>
> DMD, when specifying -od (output directory), -of (output file) and *only* when in -lib mode, treats the output file path as relative to the output directory path. Ie. -odfoo -oflibbar.a results in foo/libbar.a as opposed to ./libbar.a. This is in contradiction to every other mode (-shared, binary output, object output) and every other D compiler (ldc, gdc).
>
> This issue was raised four years ago. At the time, Walter said he was not fixing it in order to avoid breaking compatibility with existing build setups: see https://github.com/dlang/dmd/pull/4753 .
>
> People who are using build tools that call dmd: would you rather this be fixed, and have to update your code, or leave it in?
>
> (Me, I want it fixed. It's a really annoying trap for all the people who are building with dmd but aren't using -od yet, which I was among until a few days ago.)

Quite honestly, *any* DMD upgrade tends to break my build setup. Because things get changed and deprecated and added all the time, so my builds fail from compile errors.

If you can't spare a minute to update your make files during a DMD upgrade, then something has gone terribly wrong on your end.

Fix the bug.

On Monday, 12 August 2019 at 05:59:53 UTC, FeepingCreature wrote:
> DMD, when specifying -od (output directory), -of (output file) and *only* when in -lib mode, treats the output file path as relative to the output directory path. Ie. -odfoo -oflibbar.a results in foo/libbar.a as opposed to ./libbar.a. This is in contradiction to every other mode (-shared, binary output, object output) and every other D compiler (ldc, gdc).

Is there any reason, other than arbitrariness, why this is so?  e.g. are there some circumstances where using the `-lib` flag might result in more than one output file being generated (which presumably need to wind up in the same dir)?

On Monday, 12 August 2019 at 11:16:12 UTC, Joseph Rushton Wakeling wrote:
> On Monday, 12 August 2019 at 05:59:53 UTC, FeepingCreature wrote:
>> DMD, when specifying -od (output directory), -of (output file) and *only* when in -lib mode, treats the output file path as relative to the output directory path. Ie. -odfoo -oflibbar.a results in foo/libbar.a as opposed to ./libbar.a. This is in contradiction to every other mode (-shared, binary output, object output) and every other D compiler (ldc, gdc).
>
> Is there any reason, other than arbitrariness, why this is so?

Consistency? ;-) Not that DMD has a good track record on that, hence this thread I guess.

> e.g. are there some circumstances where using the `-lib` flag might result in more than one output file being generated (which presumably need to wind up in the same dir)?

There are a couple of cases in LDC (e.g. if you specify multiple -output-* flags, dcompute, PGO(?)), but the only case, i think, for DMD is -mixin (which you only care about for debugging). There probably some weird arcane combo of flags that does something unexpected though.

On Monday, 12 August 2019 at 11:16:12 UTC, Joseph Rushton Wakeling wrote:
> On Monday, 12 August 2019 at 05:59:53 UTC, FeepingCreature wrote:
>> DMD, when specifying -od (output directory), -of (output file) and *only* when in -lib mode, treats the output file path as relative to the output directory path. Ie. -odfoo -oflibbar.a results in foo/libbar.a as opposed to ./libbar.a. This is in contradiction to every other mode (-shared, binary output, object output) and every other D compiler (ldc, gdc).
>
> Is there any reason, other than arbitrariness, why this is so?  e.g. are there some circumstances where using the `-lib` flag might result in more than one output file being generated (which presumably need to wind up in the same dir)?

As far as I can tell, it's just a bug that was decided not to fix. Even if -lib generates additional output files, they should just go in the -od folder; -of should always uniquely identify the generated library file.

On Monday, 12 August 2019 at 10:29:40 UTC, Ethan wrote:

> If you can't spare a minute to update your make files during a DMD upgrade, then something has gone terribly wrong on your end.
>
> Fix the bug.

If we're constrained by guaranteeing backward compatibility with *build system bugs*, we're the most backward compatibility-constrained language in existence.

On Monday, 12 August 2019 at 05:59:53 UTC, FeepingCreature wrote:
> People who are using build tools that call dmd: would you rather this be fixed, and have to update your code, or leave it in?

I don't think I have any tools that build static libraries, but it's easy to make it work with both new and old DMD versions (just use an absolute path), so I'd be in favor of fixing it.

If you want to go the extra mile, for one or more releases DMD could warn in situations where the behavior is going to change and suggest using an absolute path to silence the warning and make the behavior future-proof.

On 8/12/19 1:59 AM, FeepingCreature wrote:
> I ran into this bug a few days ago.
> 
> DMD, when specifying -od (output directory), -of (output file) and *only* when in -lib mode, treats the output file path as relative to the output directory path. Ie. -odfoo -oflibbar.a results in foo/libbar.a as opposed to ./libbar.a. This is in contradiction to every other mode (-shared, binary output, object output) and every other D compiler (ldc, gdc).

I haven't fully refreshed my memory on this, but looking at the PR, Mr. 2015 Walter also mentioned that my PR also introduced a discrepancy in the meaning of -od for .obj files vs .lib files while fixing the original problem.

I only bring this up to point out that any new PR should take extra care to fully think through the logic and handling of the relevant flags.

> This issue was raised four years ago. At the time, Walter said he was not fixing it in order to avoid breaking compatibility with existing build setups: see https://github.com/dlang/dmd/pull/4753 .
> 
> People who are using build tools that call dmd: would you rather this be fixed, and have to update your code, or leave it in?
> 
> (Me, I want it fixed. It's a really annoying trap for all the people who are building with dmd but aren't using -od yet, which I was among until a few days ago.)

I can't test right now, but does anyone know whether these flags are case-sensitive? I know '-o' and '-O' have different meanings.

If that case sensitivity extends to -of and -od as well, then let's just assign the the new, fully rethought and fully orthogonal behaviors to '-OF' and '-OD'. That way, we get the best of both worlds: proper predictable behavior PLUS absolute unquestionable certainty of not breaking anything. We can recommend -OF/-OD as the preferred form, and then maybe phase out -of/-od or not.