Index
> Compiler Internals > %fasminc% is deprecatedGoto page Previous 1, 2 |
| Author |
|
|
bitRAKE 17 Dec 2010, 15:46
sleepsleep wrote: it is much simpler, but if let say the user want to compare then assembly their code with different fasm version, then would it means, they need to change their environment INCLUDE variable everytime?  ) it's in the INI file.
I like it just working out of the box - so to speak. USB drive, shared storage, etc. -- it all just works. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
17 Dec 2010, 15:46 |
|
|
revolution 17 Dec 2010, 15:54
sleepsleep wrote: it is much simpler, but if let say the user want to compare then assembly their code with different fasm version, then would it means, they need to change their environment INCLUDE variable everytime? |
|||
|
17 Dec 2010, 15:54 |
|
|
sleepsleep 17 Dec 2010, 16:04
hmmm,,,
from what i could see, it just a matter of name... choose %INCLUDE% or other variable that value is the include path we want to set. and i don't think it is wrong to use "FASMINC" as variable name for include path.... and it doesn't break anything. |
|||
|
17 Dec 2010, 16:04 |
|
|
revolution 17 Dec 2010, 17:10
sleepsleep wrote: and i don't think it is wrong to use "FASMINC" as variable name for include path.... and it doesn't break anything. |
|||
|
17 Dec 2010, 17:10 |
|
|
Tomasz Grysztar 17 Dec 2010, 19:34
INCLUDE name was chosen with a some kind of compatibility in mind. If you use different tools that use this standard, you can still put all the paths related to various languages into this single variable, separated with semicolons. And this is how it is a different feature from FASMINC - with FASMINC you just define a single path which you then refer in the INCLUDE directive uses; with INCLUDE you define multiple paths and fasm searches all of them until it finds the file.
That said, you can still use FASMINC and other variables when, for example, you need to refer unambiguously a very specific file, like some specific version of fasm's includes, etc. The INCLUDE variable is just a kind of overloaded bag where you put all the paths where you have something interesting, so then when you specify just a file name, tool may be able to find such file somewhere (maybe the wrong version, but that's a different story). So using FASMINC does not actually "break" anything - you can use both of those features, and each one has its own advantages. The default used by fasm's examples is the INCLUDE, because it's simpler to use and looks a little bit more "standard", and FASMW now automatically sets it up in the .INI file when the file is first created... Yes, this is not documented right now, and INCLUDE variable is not really documented, too - it appears I completely forgot about it. |
|||
|
17 Dec 2010, 19:34 |
|
|
JohnFound 18 Dec 2010, 08:56
Well, I personally don't like this implicit "include" behaviour, simply because it makes the source less readable and even confusing. Let see a part of ddraw.asm examble:
Code: include 'win32a.inc' include 'ddraw.inc' Here, despite of similar include statements, the behaviour is totally different: ddraw.inc will be included from the directory where "ddraw.asm" resides, while "win32a.inc" will be included from no one knows where, especially if there are multiply paths in the "INCLUDE" variable. Isn't it better to use explicit: Code: include '%include%/win32a.inc' include 'ddraw.inc' |
|||
|
18 Dec 2010, 08:56 |
|
|
SFeLi 18 Dec 2010, 09:33
JohnFound wrote: the behaviour is totally different The behavior is the same: if there's no such file in .asm file directory, the search will continue in INCLUDE paths. I personally find this feature very useful to extend/override a standard set of headers without having to put anything in a fasm /include/ directory: Code: data import library ... include 'api/user32.inc' ; from fasm package include 'api/sqlite.inc' ; my extra include folder end data And when I want to send this code to someone, the only thing that I need to do is pack my extra api folder with the source. Thus 'api/sqlite.inc' would be included from .asm directory and I don't have to modify a source. |
|||
|
18 Dec 2010, 09:33 |
|
|
JohnFound 18 Dec 2010, 11:30
SFeLi, it is useful when you write your code, but is it useful when you have to read someone else code, or even edit your own code after several months or years?
The problem with this future is that it introduce ambiguity about which exactly file will be included from the given statement. This ambiguity can not be solved reading source. You have to explore several other items - environment variables and ini file. In the worst case, you also, have to explore all directories listed in the INCLUDE variable and search for your file. And on top of all, if in these directories are several files with same names you have to follow the logic of priority to determine what single file will be included on compilation. |
|||
|
18 Dec 2010, 11:30 |
|
|
sleepsleep 18 Dec 2010, 13:34
imho, i think, NO assembler SHOULD automatically SEARCH a path from %INCLUDE% if it is not defined in source code.
since %INCLUDE% is used by lot of compiler, may it C, D, or other compiler, it means, there are LOTS of directories inside this ENV variables. Quote:
i agreed with above reason. |
|||
|
18 Dec 2010, 13:34 |
|
|
shoorick 20 Dec 2010, 06:22
JohnFound wrote: Isn't it better to use explicit: i think it won't work if multiply path used in "include" variable, which is quiet common. "FASMINC" sounds "includes from fasm package" for me, while "INCLUDE" has more general sense. my projects usually have "INCLUDE=%FASMINC%" declaration for local environment (as i told above FASMINC is autogenerated for me) _________________ UNICODE forever! |
|||
|
20 Dec 2010, 06:22 |
|
|
JohnFound 20 Dec 2010, 07:55
shoorick wrote: i think it won't work if multiply path used in "include" variable, which is quiet common. "FASMINC" sounds "includes from fasm package" for me, while "INCLUDE" has more general sense. my projects usually have "INCLUDE=%FASMINC%" declaration for local environment (as i told above FASMINC is autogenerated for me) The name of the variable is not important. Whether this variable will allow multiply values, or not - depends only on internal logic of FASM and in general is not important as well. The important issue here is that FASM tries to search for files on places not explicitly specified in the include statement in the source. In order to demonstrate the flaws of this "I don't want to fail" approach, let develop it further. What if FASM tries to find the included file at any cost? When the file miss from the specified path, FASM could: 1. Recursively search all sub directories of the current directory. 2. Then scan INCLUDE variable and search in all specified directories and sub directories. 3. Then it could do the same for PATH environment variable. 4. Not finding the file in these obvious places, it could switch to "heavy artillery" and try the recursive search all the disk drives of the computer. 5. Then it could try google search with the name of the file in order to attempt to download this wicked missing file. 6. After that it could simply create this missing file, include it and try to compile further. So the error "Missing file" will not appears anymore." Developing further the idea about "implicit file searching", we can see it leads to obvious irrational behaviour. So, this approach is "irrational" even in it's the partial implementation existing in FASM now. |
|||
|
20 Dec 2010, 07:55 |
|
|
shoorick 20 Dec 2010, 10:26
to say true, I never met any trouble with current fasm include behavior :S
|
|||
|
20 Dec 2010, 10:26 |
|
|
revolution 24 Dec 2010, 04:04
JohnFound wrote: 5. Then it could try google search with the name of the file in order to attempt to download this wicked missing file.  Hehe, what if the search returns multiple hits for the same name? I know, download them all and combine them into one large file. This would be a great way to inject malware also. Yeah, let's do it! 
But seriously, why the false escalation? Tomasz has never said it will get extended further, so we should take that at face value and not try to second guess hidden agendas. Perhaps the secret to solving your problem with implicit INCLUDE is just to not define it in your environment? It breaks all the provided examples of course, but I suspect that that is not a concern for you. |
|||
|
24 Dec 2010, 04:04 |
|
|
JohnFound 24 Dec 2010, 07:49
revolution wrote: ..... This example was intentionally exaggerated in order to illustrate that the implicit approach is a bad idea. You know, the wrong way does not becomes right only because you stop at the middle. Personally I never use "include" variable, but this is a matter of principle. Regards. |
|||
|
24 Dec 2010, 07:49 |
|
|
MCD 11 Jun 2011, 15:39
So, the INCLUDE variable is supposed to be a common variable for different languages, man, that's a weird. How is a C .h-file supposed to work, for example, in a python or shell script file?
|
|||
|
11 Jun 2011, 15:39 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|