flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > %fasminc% is deprecated

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
luckily i found it here....

Quote:

Revolution is talking about include 'win32a.inc' case. Don't you think it is much simpler?

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?

Quote:

No. %include% is implicit and hidden, you can't fix invisible stuff.

.......hmm,, love to know the reason behind this...
Post 17 Dec 2010, 14:45
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2913
Location: [RSP+8*5]
bitRAKE
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?
With FASMW (Wink Wink) 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)/¯ unlicense.org
Post 17 Dec 2010, 15:46
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
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?
Yes, I expect so, but it is easier to do that than change every source .asm file for each new version of fasm that you install.
Post 17 Dec 2010, 15:54
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
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.
Post 17 Dec 2010, 16:04
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
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.
Erm well ... it breaks all of the examples that come with the fasm download. It breaks most of the code posted to this forum.
Post 17 Dec 2010, 17:10
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7719
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 17 Dec 2010, 19:34
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
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'
    
Post 18 Dec 2010, 08:56
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
SFeLi



Joined: 03 Nov 2004
Posts: 140
Location: Severodvinsk, Russia
SFeLi
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.
Post 18 Dec 2010, 09:33
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
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.
Post 18 Dec 2010, 11:30
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
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:

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.

i agreed with above reason.
Post 18 Dec 2010, 13:34
View user's profile Send private message Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1605
Location: Ukraine
shoorick
JohnFound wrote:
Isn't it better to use explicit:

Code:
include '%include%/win32a.inc'
include 'ddraw.inc'
    

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!
Post 20 Dec 2010, 06:22
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
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.
Post 20 Dec 2010, 07:55
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1605
Location: Ukraine
shoorick
to say true, I never met any trouble with current fasm include behavior :S
Post 20 Dec 2010, 10:26
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
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.
OMG Shocked 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! Twisted Evil

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.
Post 24 Dec 2010, 04:04
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
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.
Post 24 Dec 2010, 07:49
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
MCD



Joined: 21 Aug 2004
Posts: 604
Location: Germany
MCD
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?
Post 11 Jun 2011, 15:39
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.