Index
> Main > FASM define macro from commmand line - "-d" switchGoto page 1, 2 Next |
| Author |
|
|
sid123 26 Dec 2014, 11:04
Does fasm have something like gcc's -D option?
For example if you want to define a macro from the compiler itself, you can do something like this: Code: gcc -DSOME_FLAGS -c code.c -o code.o ... "code.c": #ifdef SOME_FLAGS ....some more code.... #else ....some code... #endif It would be quite useful in fasm, since we could use automated build tools, than explicitly modifying an include header itself. _________________ "Those who can make you believe in absurdities can make you commit atrocities" -- Voltaire https://github.com/Benderx2/R3X XD |
|||
26 Dec 2014, 11:04 |
|
|
l_inc 26 Dec 2014, 13:16
sid123
You could achieve the same effect using environment variables. You'd need a separate file for each elementary set of configuration options though. For being able to configure each flag independently you'd do smth. like this: Code: rem compile.bat set SOME_FLAG1=some_flag1_enabled.inc set SOME_FLAG2=disabled.inc fasm.exe -m 1572864 project.asm Code: ;project.asm include 'config\%SOME_FLAG1%' include 'config\%SOME_FLAG2%' match ,some_flag1 { ;if flag1 enabled ;....some more code.... rept 0 \{ } match, { ;if flag1 disabled ;....some code... } Code: ;some_flag1_enabled.inc
define some_flag1 Code: ;some_flag2_enabled.inc
define some_flag2 The file disabled.inc is just empty. Any possible adjustments to this approach are limited to your fantasy only. 
P.S. Here's btw. one possible adjustment, where you just echo the configuration options into an included file. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
26 Dec 2014, 13:16 |
|
|
revolution 26 Dec 2014, 13:52
|
|||
|
26 Dec 2014, 13:52 |
|
|
Tomasz Grysztar 03 Jan 2015, 23:13
I removed the -d option back then after being accused of breaking my own principles. But, in fact, the SSSO has always had somewhat blurry boundaries, because the line between what is considered a "source" and what is not is a fuzzy one. After all, I always interpreted the "source" to include the structure of files, environment variables, and even system time. To count some command line switches among the source structures is then an arbitrary choice, and it would not go against the core of SSSO principle: that one should not be forced to use additional settings like command line options or environment variables - that it should always be possible to define everything just by editing the source text. The existence of directives like FORMAT is what the SSSO was really about, and the removal of "-d" option was just me being misled by my own wording.
With this all in mind, I may actually bring back the "-d" switch, because for the future I plan to return to that original thought that was behind "SSSO" and not let the stricter wording be an actual rule. |
|||
|
03 Jan 2015, 23:13 |
|
|
cod3b453 04 Jan 2015, 00:37
When I'm sharing definitions between FASM and anything else I define a common file (FASM/text list/XML/...) that I then auto-generate FASM/C/C++/batch/shell/... headers from using either FASM [lots of files
 ; spectacular possibilties  ], batch/shell scripts or build tool (if using something like cmake this can even do the conversion for you across platform with the string and file handlers, if it's simple). If you've already got definitions in a FASM/C header you may be able to retro fit using this using the same automated conversion though this is gernerally more tricky due to parsing. |
|||
|
04 Jan 2015, 00:37 |
|
|
l_inc 04 Jan 2015, 01:22
Tomasz Grysztar
I hope this decision was not induced by the kind of misuse of environment variables that I demonstrated in my previous post. Because if I remember correctly, the SSSO principle arised out of the problems related to not knowing the correct command line to make those damn sources compile. The -d switch might bring us back to such situations. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
04 Jan 2015, 01:22 |
|
|
Tomasz Grysztar 04 Jan 2015, 10:42
l_inc wrote: Tomasz Grysztar The point should not be to strive to make it impossible for anyone to create such sources - my actual (and more realistic) objective was to make it possible to create sources that would be self-sufficient and assembled in the same way on any platform, and to make this an easy to use standard. Encouraging is better than enforcing, especially when such enforcing could lead to removal of many useful features. |
|||
|
04 Jan 2015, 10:42 |
|
|
AsmGuru62 04 Jan 2015, 13:36
One of the things I use in my code are assertions.
So, to make the build without assertions - I must change a line in the source. To bring assertions back, I have to edit the source again. It would be nice to just use the command line to do it - instead of using environment variables. My point is: SSSO principle is great, but not where assertions are involved. |
|||
|
04 Jan 2015, 13:36 |
|
|
revolution 04 Jan 2015, 13:41
I am curious to know why you need to disable assertions?
I also use assertions but I keep them there for all time. |
|||
|
04 Jan 2015, 13:41 |
|
|
Tomasz Grysztar 04 Jan 2015, 14:42
revolution's well-founded question aside, it should be possible to directly disable the assertions with the "-d" switch, try command like "fasm src.asm -dassert=times(0)".
The implementation of "-d" that I brought back does not support quoted values, so it is not possible to define values containing spaces. Last edited by Tomasz Grysztar on 04 Jan 2015, 15:14; edited 1 time in total |
|||
|
04 Jan 2015, 14:42 |
|
|
revolution 04 Jan 2015, 14:45
Is -d the same as "fix" or "equ"?
|
|||
|
04 Jan 2015, 14:45 |
|
|
Tomasz Grysztar 04 Jan 2015, 15:16
It's the same as "define".
|
|||
|
04 Jan 2015, 15:16 |
|
|
l_inc 04 Jan 2015, 16:33
AsmGuru62
Your situation is really something absolutely not requiring the "-d" switch. An orthodox design for fasm sources would be to have different base files with configurations like the sources of fasm do: fasm.asm, fasmw.asm, fasmdll.asm, etc. Those basically share most part of the sources and define configurations. The same should be done in your case: myproject.asm + myproject_dbg.asm. The latter defines all the constants you need for your debug configuration and possibly includes myproject.asm. The compilation output depends then merely on the command line as you wish that: "fasm myproject.asm" or "fasm myproject_dbg.asm". revolution Quote: I am curious to know why you need to disable assertions? I assume AsmGuru62 means a kind of runtime assertions, which might induce performance penalties if included in a release configuration, but are desirable for unit testing or similar. Tomasz Grysztar Quote: Even wihtout "-d" it was still possible to create a source that required some additional setup Sure, but it was less obvious and more complicated. And hence discouraged by design. Quote: my actual (and more realistic) objective was to make it possible to create sources that would be self-sufficient and assembled in the same way on any platform, and to make this an easy to use standard. Encouraging is better than enforcing And how exactly does "-d" switch encourage that? _________________ Faith is a superposition of knowledge and fallacy |
|||
|
04 Jan 2015, 16:33 |
|
|
AsmGuru62 04 Jan 2015, 16:34
I am not sure what assertions are we talking about.
I am talking about run-time assertions, like checking if index into array is within the current (dynamically allocated) range of the array. Obviously, these checks are made for debugging and in released version - the checks should not be in place to make code faster/smaller. |
|||
|
04 Jan 2015, 16:34 |
|
|
AsmGuru62 04 Jan 2015, 16:38
l_inc
I am not sure if keeping two source files is a good solution. |
|||
|
04 Jan 2015, 16:38 |
|
|
l_inc 04 Jan 2015, 16:47
AsmGuru62
If you have anything other than a tiny piece of code, then you have your project spread across multiple files anyway. It's just best practices. Additionally if you share your code with other people, it should include all the information one needs to compile it in whatever configuration. And this would require you to have additional files anyway*: either by making a kind of a makefile with all the possible command lines included or by providing different base files. I would really prefer the latter solution. * I personally dislike solutions that mix batch command files together with the source code. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
04 Jan 2015, 16:47 |
|
|
Tomasz Grysztar 04 Jan 2015, 17:20
l_inc wrote:
|
|||
|
04 Jan 2015, 17:20 |
|
|
Tomasz Grysztar 04 Jan 2015, 17:24
AsmGuru62 wrote: I am not sure what assertions are we talking about. |
|||
|
04 Jan 2015, 17:24 |
|
|
l_inc 04 Jan 2015, 17:41
Tomasz Grysztar
Quote: It does not and I did not suggest that it does I know. My question rather suggested that "-d" switch is not much of a help for whatever else. Quote: On the other hand, the removal of "-d" was an attempt at enforcing this 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 (without making impossible) 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? _________________ Faith is a superposition of knowledge and fallacy |
|||
|
04 Jan 2015, 17:41 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|