.
I'm moving the new posts previously bumping an obsolete 1 year old announcement thread t=7902 here in DOS386 2008-12-30
.

vid: It has been a year now. I am still holding my breath waiting for your example. And thanks for taking the extra time to make your example really good (after 1 year I imagine the example is now perfect?).

Expectantly yours,
revolution

Okay... you have a larger project, with many source files, each compiles to separate object and finally they are linked - pretty common for normal projects. You want to compile this project for different targets - such as debug version, release version, version with some features disabled, etc. - again common requirement.

Now how would you do it without -D ? One option is to have a config file, which is included from every source file, that has all symbols you need. But that would mean if you want complete rebuild (rebuilding all targets, for example to see if your last change didn't break any target), you would have to edit that config file several times by hand - very inconvinient.

You could "solve" this by using environment variable to access different config file from same sources. But using envvars this way is something even Tomasz considers breaking the SSSO, so there is really no principal difference between breaking it like this, or breaking it with -D (except that latter is much more flexible and nicer).

Or, you could also use some utility to generate configuration file and then rebuild, but that is really hacking around the SSSO just to avoid obvious solution.

And now, even more fun: Imagine your project uses more languages: Asm, C, Python, whatever. Of course, you should be able to set target in single place for parts in all languages. Any of already proposed two solutions means, if you want to prevent duplication, you have to generate the config file for ASM part separately, and command line for other languages separately, probably from some common source. So you need complicated very custom pre-build steps just to avoid straightforward solution.

If you know about any other good solutions to described problem, let me know.

I use "header" type files to build different versions. Usually they are just .asm files with a few definitions of constants and an include. With the -d style don't you still need batch files of some type? If you are typing the -d option manually each time then I think there is a tendency to lose the audit trail of what has to be typed to get the thing to compile.

This is one aspect of C that really bothers me, the need to specify the compile options in a separate doc file (or on a web page somewhere). Does the same thing not happen in asm files with -d? How can you avoid the loss of audit trail? If you use batch-type setup then it becomes the same as a simple .asm file as a header? What did I miss? I tend to miss some obvious points on occasion so I wouldn't be surprised if I misunderstood something obvious.

An example would be nice.

I totally agree revolution, -d is the first step into the nonsense that are make files (or any other stupid complicated linking method). If anyone has wasted time on linux goggling the net trying to work out why some simple app won't compile they'll know what I mean. It still surprises me Tomasz allowed it..... I actually thought he knew better!

MichaelH: I'm still assuming there is a good reason for it but so far I can't see it. I am hesitant to say anything bad about it, because I don't know enough yet to properly judge it's merits.

vid: I know that you have in your mind a really good reason for it, and I don't doubt your motives. But, how do we copy that reason out of your mind and paste into this forum? Perhaps you have a particular project that you worked on that really really needed -d? Yeah? Perhaps you can cut and paste some bits of it to show how -d helped? I am keen to see if it would help me in my coding also. Maybe I am just stubborn and need some powerful convincing before changing my habits, but usually, if I see the good reason (when there is one, of course), then I change and work better/faster.

BTW: Just by way of comparison, whenever I make multi-lingual programs I never use different sources to assemble multiple .exe versions. I always include all language dependent strings in one .exe that all clients run. One .exe version means only one headache to manage. Then the runtime system will define the language used through either a menu option, a startup parameter or a config file. Very flexible, no need to find the right language version to install, no batch files or compile options to set.

Yes, you need some makefile (you can use batch, but makefiles are much more convient in bigger projects, otherwise compilation takes ages).
But remember, I said that project has to be split into multiple object files, as is usual practice in most languages and for a good reason - most importantly speed of re/compilation. Recompiling everything every time is unbearable for bigger project. So you have to split source into objects, and therefore you need some batch anyway to compile all modified objects.


There are several key differences:
1. If you have more build targets, manually modifying the header file to switch between them is much harder than using makefile. You can make single makefile where all targets are listed, and recompile simply by "make release" or "make debug".
2. Header file cannot be shared in multi-language project, while some sort of batch or makefile with -d option can do this easily. You *could* generate header file from batch, but that is much harder than specifying -d option, and you would have to have some source to generate header from anyway.


Not really different sources, that sounds like code duplication, which is bad. I meant something like:

In makefile, you have two options, if it is called by "make debug" you call fasm with "-d DEBUG=1", if it is called by "make release", you call fasm with "-d DEBUG=0". This method also allows you to easily share setting between parts of project written in different languages, eg. you also call C compiler with "-DDEBUG" or without it.

Some more/less real world example (i can't post sources for obvious reason): I am working on hypervisor project of which part is written in C, part in ASM. I have 4 targets for now - Win64/UEFI64, debug/release. There can easily be more in future: Win32, linux, etc... I want to be able to easily "switch" between these targets, without having to go over header files and editing them. How would you do this, without -d support in FASM? I would need to always generate some ASM header included by all .asm files.

I can use batch file to conditionally select one of a set of .asm files to assemble if that is what is required (could the make do this also?). The .asm files are simply one/two lines to define the constants and one line to include the main code. This seems to me to be the same functionality of the make style of doing things. If you are using a make program to control the project then could you not also use it to include the appropriate .asm "starter" file? With sensible naming the file name contains the option name within it making it clear in a directory listing what options and/or settings are available. I guess that you see it as a good thing and I'm not criticising, but -d does seriously break SSSO (one of the core reasons why I use fasm). Perhaps I just misunderstand the make way of doing things. I am very sorry if my arguments seem stupid and naive.

BTW: When I mentioned about assembling different sources I meant only what I have explained here: with just the minor change of the selection of the starter .asm file. To me that is a different source that fasm sees. The net effect is the same as the -d method, both would assemble the target in the same way.

FYI: In the interim I had banned all my staff from using the -d option until I can find a good argument to allow it. None of them could justify to me where or why they may need it. All cases they brought up were easily solvable with other means that already exist.

But you need to realize there can be many .asm files which need to be compiled separately. Would you have separate header for each file and each target (duplication, zounds of files just to achieve the target)? Or would you include code file from header file using envvar(SSSO broken anyway)? Or how?

Aha, the penny just dropped. That was the missing piece. I will have to think about this some more.

Thanks for your patience, I finally see the problem you need to solve.

So it seems it becomes a matter of degree. If, say, you have 23 languages to support, each with 10 levels of functionality, and each again with 4 target systems, and you wanted all separate .exe files, then you would need 23*10*4=920 different "starter" files. And in such a situation that would clearly be unmanageable with a file based option selection.

My company culture here is to always actively try to reduce dependence upon having to choose the correct .exe to install/use/test. I always felt multiple .exe's confused matters greatly for the client/user (and me). Things like upgrades become problematic and troublesome to test well. If I was faced with the above scenario (the 23*10*4 thing), then the standard way of dealing with it is to make only the 4 target system versions and every other option every client gets (with runtime selection for the extra options). So for me such a thing as only four (or whatever small number, often no more than two) versions always seems trivial to solve.

I think I have a good handle on this issue now. Please feel free to correct any misunderstanding may have in the above.

You're welcome.

Only thing you seem not to be understanding (sorry if not), is that separately compiled files are not there to build multiple EXEs. They are built to multiple .OBJ files, which get linked into single EXE (or DLL in my case).

That is standard way to code pretty much everywhere outside FASM community, and for a good reason: compilation usually takes ages, so splitting project into many objects allows you to recompile only objects which changed since last compilation. Such coding style is also somewhat cleaner, because it forces you to declare precise interface between modules, not so much "access everything from anywhere" as with single-source-to-EXE. You can also use static libs without recompiling them every time. Ever wondered why many FASMers always look for libraries in DLL, even though it is "more files" then and they don't share those libraries anyway?