www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Poll: -od -lib -of and breaking compatibility with build tools

reply FeepingCreature <feepingcreature gmail.com> writes:
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.)
Aug 11 2019
next sibling parent Seb <seb wilzba.ch> writes:
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.
Aug 11 2019
prev sibling next sibling parent kinke <kinke gmx.net> writes:
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).
Aug 12 2019
prev sibling next sibling parent reply Ethan <gooberman gmail.com> writes:
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.
Aug 12 2019
parent bachmeier <no spam.net> writes:
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.
Aug 12 2019
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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)?
Aug 12 2019
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 12 2019
prev sibling parent FeepingCreature <feepingcreature gmail.com> writes:
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.
Aug 12 2019
prev sibling next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Aug 13 2019
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Aug 14 2019