If no other path elements than those specified in source were used to compose such value, it would probably not break the SSSO principle

Do the environment variables (including the variable Include) belong to those path elements specified in the source?

They would have to stay unexpanded in that value.

#ifndef __UNISTD_H
#define __UNISTD_H

;rest of header file here

#endif    

;first.inc
match =_first_inc,_first_inc { define _first_inc +

;header code

}    

Hmm - was trying to write a basic short macro that would do that - but i cant because I cant find a way to match a undefined constant, and without that.. you cant do the ifndef trick..

I've tried to find a way, but it doesnt seem to be possible to do a match on a constant which currently doesnt exist - i mean, it assembles.. but it always assembles false, theres no special word or symbol that can be used to do "if not defined" using match?

match =SOME_CONSTANT,SOME_CONSTANT {
  define SOME_CONSTANT something different
  ; this will not get assembled next time
}    

E.g. I'd like to be able to pass the value of !p to the file directive, cause include 'win32a.inc' works fine because of prepending one of the paths from the Include variable, but file 'win32a.inc' would not make use of the Include variable and therefore would not work.

Wouldn't it be simpler to just make "file" use the same file searching rules as "include"?

format binary as 'asm'
include 'selfcompile.inc'
include 'main.asm'
    

;Compiles all includes together into a source file
include fix include_directive_modified
include_directive_original fix include

included_files_list    equ
included_files_output equ ''
include_file_output_indentation equ ''
macro def_include_directive_modified
{
 macro include_directive_modified arg*
       \{
            tmp equ included_files_output
                       restore included_files_output
                       included_files_output equ tmp,include_file_output_indentation,"'",arg,"'",' included',13,10
         restore tmp
         
            match '',include_file_output_indentation \\{ if 0 \\}
               
            def_include_directive_modified
              include_file_output_indentation equ include_file_output_indentation,'   '
                 include_directive_original arg
              restore include_file_output_indentation
             purge include_directive_modified
            
            tmp equ included_files_list
                 restore included_files_list
                 included_files_list equ tmp arg
             restore tmp

             match '',include_file_output_indentation
          \\{
                  end if
                      display included_files_output
                       match list,included_files_list \\\{ irps f,list \\\\{ file f \\\\} \\\}
                   restore included_files_list,included_files_output
                   included_files_list equ
                     included_files_output equ ''
              \\}
  \}
}
def_include_directive_modified
db 'include fix include_directive_modified',13,10
db 'macro include_directive_modified arg* {}',13,10    

This is in fact a bug fix, because fasm's manual was stating that the same rules apply to both of them, but it was not true.

Quote:

This is in fact a bug fix, because fasm's manual was stating that the same rules apply to both of them, but it was not true.

I actually never considered this to be a bug, because previous documentation versions never mentioned the "Include" variable usage for the file directive; and the manual statement: "These rules concern also paths given with the file directive" — was applied in the context of explicit environment variables specification (with surrounding % signs) and searching within the main source directory.

Regarding your concerns about the SSSO principle I never understood, why it can't be violated. Changing the "Include" variable also changes the output by using different include files without any modifications to the main source file.

(which however reduces the value of the SSSO principle, because header files are often not distributed together with the main source components)

(...) then SSSO is still violated by the file directive, because replacing the included file changes the output without changing the source.

And, speaking of "includeonce" problem - consider, for example, that you have a hard link in filesystem, so you have one file under two different names. That's another system-dependent thing, and there isn't much you could do about it.

as long as you are able to ensure that the same files are provided under the given names by the system, the SSSO rule still applies

You'd just need to extend the SSSO definition with "as long as you are able to ensure the same environment variable values are provided under the given names by the system" which is apropos already partially included by the need to provide same files (consider for example file '%WinDir%\system32\kernel32.dll'). IMHO SSSO borders are already crossed, you just decide how far.

Alternatively, if you want to match the undefined constant, you can just match it with its name:

Code:

match =SOME_CONSTANT,SOME_CONSTANT {
  define SOME_CONSTANT something different
  ; this will not get assembled next time
}    

I did not know you could do that, thanks... It's also not mentioned in the documentation? might be worth a mention, can be a useful feature to see if a constant is defined (for default values that can be overridden/etc).

match x,FILE_INC {    

and the 'x' is used to "match anything" -- in other words, it matches any symbol(s) available, which happens all the time unless the symbolic constant is empty...

match y,FILE_INC {
match aaaa,FILE_INC {
match asdf, FILE_INC {    

Now what happens, when the name symbol is not preceded with = in the expression to be matched? Back to the manual:

fasm manual, section 2.3.6 wrote:

If some name symbol is placed in the pattern, it matches any sequence consisting of at least one symbol and then this name is replaced with the matched sequence everywhere inside the following block, analogously to the parameters of macroinstruction. For instance:

Code:

    match a-b, 0-7
     { dw a,b-a }    

will generate the dw 0,7-0 instruction.

So for the duration of the code inside the match{} (the first time round, when FILE_INC is undefined, and hence equal to "FILE_INC"), then x (or y, or aaaa), will be defined as "FILE_INC"? whereas once FILE_INC is defined, and blank, then x (or y...) will not have any sequence/string to match against, and so the match will fail?

include 'file.inc'
purge FILE_INC
include 'file.inc'    

In my opinion theres no need for the !p since match can do the job nicely. If you do want to include a file multiple times, you could simply purge/undefine the constant before you include it the second time.. so:

match x, _FILE_INC
{ 
  define _FILE_INC
  include 'file.inc'
}    

match , _FILE_INC {
stop_preprocessor
}
define _FILE_INC

.. rest of header code..