Fix Issue 14305 - DMD incorrectly interprets -of and -od with -lib...

[Abscissa]

…(also fixes Issue 14296).

https://issues.dlang.org/show_bug.cgi?id=14296
https://issues.dlang.org/show_bug.cgi?id=14305

[CyberShadow]

This is some odd logic... With -odA, -ofb.lib and -ofA/b.lib would do the same thing?

[Abscissa]

Hmm, ok, I think I managed to have a bug and a misunderstanding of -od manage to cancel each other out. This does the right thing, but for the wrong reasons. Gonna revisit and reopen this after some sleep.

[Abscissa]

Ok, I reworked it.

[WalterBright]

What bothers me about this is now -od has a different meaning for .obj files and for .lib files. This is intensely confusing. If -od, -of, and -lib are all given, then the path should be stripped from the -of name, and the path from -od used.

[CyberShadow]

What bothers me about this is now -od has a different meaning for .obj files and for .lib files.

This also applies to the current situation (see description of issue 14305).

. If -od, -of, and -lib are all given, then the path should be stripped from the -of name, and the path from -od used.

I think it would be better to ignore -od (and only use it for intermediary files) if -of is specified, for -lib to be consistent with non--lib usage, no?

[WalterBright]

1. there's how obj, lib, exe, dll, html, etc. files are generated. This should all be consistent.
2. I am reluctant to simply change all this around, as who knows what makefiles and build systems will get broken. Such a change could highly annoy many users.

The only solution I can see is to define a new switch, and define some systematic and consistent behavior for it. Leave -od as it is.

[CyberShadow]

1. This should all be consistent.
2. I am reluctant to simply change all this around

These are mutually exclusive as I understand

[CyberShadow]

Looking at the code, I think this patch is done in the wrong place, and should instead be done in Lib*::setFilename (which, BTW, is identical across all four Library implementations and should be refactored).

They contains the following code:

    const char *arg = filename;
    if (!arg || !*arg)
    {   // Generate lib file name from first obj name
        const char *n = (*global.params.objfiles)[0];

        n = FileName::name(n);
        arg = FileName::forceExt(n, global.lib_ext);
    }
    if (!FileName::absolute(arg))
        arg = FileName::combine(dir, arg);

The second if block should be moved to the end of the first if block, so that the -od switch only applies to automatically-generated output filenames, and not any explicitly-user-specified filenames.

[MartinNowak]

What's the state of this?
Why do we need to fix an rdmd bug in dmd.
If it addresses a regression it should go into the stable branch.

[CyberShadow]

Why do we need to fix an rdmd bug in dmd.

https://issues.dlang.org/show_bug.cgi?id=14296#c1

[WalterBright]

Again, I think it is a BAD idea to change the behavior of -od. It's a fine way to make people mad. To change the behavior, a new switch must be created, or fix rdmd to use fully qualified names.

[ibuclaw]

As per comments last comments, I will close this.

@Abscissa - Please rebase and reopen if you think that this should be pursued in a new light.

[FeepingCreature]

I've just ran into this behavior of -od. Let me just say that the crazy, lolrandom way that it currently works is making me plenty mad on its own.

I'd rather dlang make some people mad now rather than make every future user mad when they find out.

[FeepingCreature]

Update: opinion on the forums seems unanimously in favor of 'fix it, please'.