Add -versions option to list predefined version identifiers.

[alexrp]

This is something I find myself desperately needing in my build system; it's much more robust to ask the compiler what the target configuration looks like than trying to do target triple hacks like in Autotools and such.

[yebblies]

Could one of the existing compiler switches be extended to include this information? Maybe -v?

Please don't use tdata in new code, array now has an overloaded index operator.

[alexrp]

-v doesn't make the compiler exit, so probably not.

Will fix the indexing.

[alexrp]

Fixed.

[yebblies]

The compiler will exit by itself if you don't pass any files. I think this is useful, but we could do without more switches. Another option would be to do this inside the compiler as a __trait, you could then output it the list in whatever format you liked.

[alexrp]

The compiler will exit by itself if you don't pass any files.

Just dmd -v prints the full help thing which isn't very useful. The output should only be the version identifiers.

I think this is useful, but we could do without more switches.

I really don't get the aversion to compiler switches. I know we don't want the clutter that e.g. GCC has, but we're far from that anyway. We'd have to add a ton of -Wfoo and -fbar options to get such a mess, and I can understand why we'd want to avoid that, but compiler switches like this one are fairly harmless.

(Relatedly, maybe we should just consider cleaning up -help so it has sections instead of the current 'list everything in one huge list' approach...)

Another option would be to do this inside the compiler as a __trait, you could then output it the list in whatever format you liked.

Doing it in a trait would require a lot more boilerplate though, since we'd then have to keep a separate list of predefined identifiers in addition to the ones defined by the programmer.

[alexrp]

Also, there are some downsides to a trait:

• It's much slower.
• It complicates the whole thing; now you have to write a source file and hand it to the compiler instead of just piping the compiler's stdout when passing -vver.
• (I'm not sure if it'll play well with cross-compilation. I haven't really investigated this area much.)

[dnadlinger]

Not sure about the name -vver, as the -v prefix seems to imply that compilation still proceeds at usual.

Regarding doing it as a trait, I am not sure if excluding user-defined (if by "defined by the programmer" you mean command line arguments) is actually desirable. There doesn't seem to be a good reason why you should want one but not the other, especially because they could also be added from the config file/an env var. Why wouldn't you want to know these version identifiers?

@yebblies: The compiler will exit immediately if you don't pass any files, yes, but with an error code instead of returning 0. This can be annoying to handle in build systems.

[alexrp]

Why wouldn't you want to know these version identifiers?

Because the programmer can cheat:

dmd -version=ARM # suddenly that list isn't so useful anymore

Not sure about the name -vver, as the -v prefix seems to imply that compilation still processes at usual.

Maybe -versions?

[dnadlinger]

Why should "the programmer" want to trick his own build system into obtaining wrong results?

[dnadlinger]

Oh, but yes, in general, I see how a way to obtain the predefined versions can be useful in build systems, if they want things to »just work« in the user's respective environment. If the patch is accepted, I'll definitely add something similar to LDC.

[alexrp]

Why should "the programmer" want to trick his own build system into obtaining wrong results?

An incorrectly configured environment could result in such things. My point is that it's error prone, not that you'd want to actually do it on purpose. ;)

Any thoughts on -versions instead of -vver?

[dnadlinger]

If the environment is configured incorrectly, then why shouldn't you want to know about it, if you are subsequently going to build your code under the same configuration?

[alexrp]

But that's the point, I won't know about it: The build system will just think it's building for ARM while in reality it's building for x86 and then everything blows up at some point in the compilation process (or worse yet, at runtime).

If you use the predefined identifiers from the compiler, untouched by the environment, you will always get a sane result and can trivially print a "building for arch FOO" message to the user (that message would be lying if the environment was misconfigured).

[dnadlinger]

No, the point is that it doesn't matter if you know about it, you will be in serious trouble anyway, because your own code (which might contain version statements – Phobos certainly does, at least) will be compiled with all the version statements in effect, not just the blessed, predefined ones. Listing all the version statements has the advantage that you actually see what's going on, instead of restricting yourself to just knowing a basically arbitrary subset of all versions which might or might not (!) be effect during compilation of your code.

I certainly would find it very surprising if I ask DMD to print a list of predefined switches, but later discover that another version is active as well during compilation. From a user perspective, there is little to no difference between whether a version is defined in dmd.conf or the compiler itself.

[alexrp]

It doesn't have any advantage unless you're expecting the build system to actually present to the user the list of version identifiers on every build so that they can validate it or, somehow, try to work out if there are contradictory version identifiers in the list (this could never be done reliably enough; Autotools as a whole should be proof of this).

Right now, -vver as it's implemented here does the right thing for free because it just lists the predefined version identifiers before others are added. From what I understand, you want it to go after user-defined version identifiers have been added, which makes the code less trivial (due to how the command line switch processing loop works). I just don't see any compelling use case for that other than propagating bad configuration into the build system, which most likely won't be able to deal with it sanely anyway.

Please clarify if I'm misunderstanding...

[alexrp]

Now -versions instead of -vver.

[alexrp]

ping

[alexrp]

Can we please get this into the next release so we can get a better build system story than stone age C?

[ghost]

To satisfy both camps maybe we could print both built-ins and user-defined versions but separate them? e.g. --versions would print:

predefined versions:
ARM
Posix

user versions:
X86

It would take a little bit of text post-processing but it shouldn't hurt much?

[alexrp]

But, see, with a design like that, the build system will just deliberately ignore the user-supplied version identifiers. Which means that outputting them has no value at all.

[dnadlinger]

Still not happy with the fact that command line, and thus also dmd.conf, arguments are ignored by design.

In my opinion, there are two possible designs for -versions, the latter of which I prefer:

1. Print the versions in effect when running dmd myprogram.d without any extra parameters.
2. Like 1., but also include versions defined as a result of command line parameters (e.g. dmd -m64 -versions on a DMD installation which defaults to 32 bit compilation would show X86_64).

If I remember correctly, the current patch implements neither of the options, as it completely ignores all parameters, also the ones from sc.ini/dmd.conf. I think there is no reason to do that, as from a build system perspective, they are as much part of the environment as any built-in defaults.

For example, consider that an user's compiler configuration file could have -mtriple=arm-linux-gnueabi, which completely changes the set of »predefined« identifiers – or less drastically, but realistic with today's DMD, -m32/-m64. Why would you want to ignore that when writing a build system?

[alexrp]

I can somewhat understand wanting to include command line options from the configuration file into the output of -versions. However, DMD doesn't seem to think that modifying architecture from the configuration file is a good idea: https://github.com/D-Programming-Language/dmd/blob/master/src/mars.c#L908-L910

[WalterBright]

I'm thinking that we are reinventing JSON files badly. Maybe this stuff should be added to the JSON output instead?

[alexrp]

No. This is simple information that needs to be queried before a build, not after it. Outputting it to a file would also complicate things a lot, unnecessarily. Suddenly you have to find a place to put the file and then read it rather than just reading the stdout/stderr of dmd.

[jpf91]

OT: It's true that for IDEs and build tools JSON output mode would probably be nice. Things such as compile errors/warnings, "-vtls" output etc as JSON written to the console output would make it very easy and fail safe to parse. But this should always be in addition to user readable output, not as a replacement.

[andralex]

This seems controversial. OK to close for now?

[alexrp]

I retract my argument that command line flags shouldn't be included in the output for one reason: gcc -dM -E -DFOO - < /dev/null includes #define FOO 1. So, consistency.

Given such a change, would this patch be acceptable? If so, I'll revive it.

(I'm bringing this back up because I'm writing a build tool at present, and I'm pretty much stuck when it comes to making cross-compiling sane because I can't grab this information from the compiler.)

[ibuclaw]

@alexrp - can you please rebase this taking in @klickverbot 's considerations.

Some other notes:

1. The frontend now prevents the user using eg: -version=ARM since this pull was raised.
2. I think this has valid use as, eg: gdc may load up a different set of predefined version conditions depending on target flags such as -mandroid or -msoft-float which can change the behaviour of program if there are different codepaths in place for version(Android) or version(D_SoftFloat) respectively.

[andralex]

ping @alexrp

[WalterBright]

This is good to go with the following changes:

1. rebase
2. use -version as the switch
3. print out the version identifiers as they exist after the command line and all environment settings are done, but before compilation starts.

[PetarKirov]

-version is already used to "print compiler version and exit". That can be confusing considering the other two meanings ( -version=), but -version is de facto standard for printing the version of command-line applications.

[WalterBright]

Thanks, I didn't realize that. I fine -versions and -version to be a little too similar, though. I'll think about it some more.

[PetarKirov]

Yeah, I agree that -version and -versions sound too similar. The only solution that I can think of is to rename -version= and the proposed -versions to something like -dversion= and -dversion (or -dversions) or something else different enough from -version.

[mathias-lang-sociomantic]

Could we use dmd -version=? like it's done for -transition ?

[PetarKirov]

@mathias-lang-sociomantic dmd -version=? works for me.

[JinShil]

This PR would probably succeed if it had the following:

1. Rebase
2. Use version=?. Precedent has already been set with -transition=?
3. Print out the version identifiers as they exist after the command line and all environment settings are done, but before compilation starts.

I'll revive it if someone wants to explain how to accomplish 3.

[ibuclaw]

Note, a PR was merged that added all versions to the output of -v. Anything added should reuse that code.

[JinShil]

Note, a PR was merged that added all versions to the output of -v. Anything added should reuse that code.

That PR was #7084. Given that, the fact that @alexrp has not voiced a desire to continue pursuing this in quite some time, and the fact that there doesn't appear to be much demand from anyone else, I suggest this be closed. Are there any objections?

[JinShil]

I suggest this be closed. Are there any objections?

No objections were raised. Closing.