As you already explained, it's just a matter of definition whether you call something a part of a source or not. Hence the elusive meaning of the SSSO principle was probably a wrong motivation, but I think removing the "-d" switch wasn't such a bad idea, because this discouraged rather inappropriate organizations of source code. Bringing the switch back again not only makes it possible but also encourages.

Or do you just disagree that it's much better to have different base files for different configurations (or a separate editable config.inc for other use cases) rather than to have in mind some unobvious possible configurations definable by putting something into the command line?

version 1.71.32 (Jan 04, 2015)

[+] Brought back the "-d" switch for command line.

version 1.71.31 (Dec 08, 2014)    

The features like FORMAT do encourage to create self-sufficient sources. On the other hand, the removal of "-d" was an attempt at enforcing this, and in my opinion it was doomed to fail because by the same reasoning not only use of environment variables or time stamp, but even the INCLUDE directive in itself could be removed from language, and this never even crossed my mind

Gitian uses a deterministic build process to allow multiple builders to create identical binaries.

Is it means that if there is a project that needs such definitions in the command line, it will not be possible to be compiled with FASMW?

JohnFound wrote:

Is it means that if there is a project that needs such definitions in the command line, it will not be possible to be compiled with FASMW?

Such definition is not different from putting the "define" in the beginning of source and if any project requires such definition, it is still more natural (IMO) to add a new line to the source instead - this was the point in the above discussion. The command line switch is more useful only in the case of automated build scripts that combine works of various tools/compilers (there only the command-line version of fasm is applicable). When you assemble from fasmw, you assemble the pure fasm's project and then modifying "define" lines on top of the source is a simple and intuitive way of obtaining the same result.

So, IMHO, -D option is very, very controversial feature.

It was [a] controversial feature ...

if I include these define statements at the beginning of the source file, they will always override these defined by -D command line option

Also, IMO, the loose definition of "source" is contradictory. Following it, we are coming to something that can be "source" for console FASM, but "not source" for GUI FASM versions.

Also, notice the point of l_inc about the symbolic constant stack

Everything that can be done with -D option can be done without it as well

IMO, whatever the definition of "source" is, it must be the same for all versions of FASM. But this is not the case with -D option.

IMHO the "-d" option (if it's there) should work the same way as if there was a declaration of the corresponding constant at the very beginning of the source. I.e. the overriding is done in the normal way of adding the new value to the already existing stack instead of creating a new clean one.