File search paths

[donkey]

Hi Jeremy,

If I have a file that I am including in a source that has a line that includes another file via #include will GoAsm search for the secondary file in the same path as the original included file or will it only search the standard paths.

Code Select Expand

*********************************
;test.asm

#include \someroot\somedir\header1.h

...
*********************************

*********************************
;header1.h

#include header2.h

...
*********************************

In the previous example would header2.h be found if it also resided in "\someroot\somedir\" ? If not is it possible to fix it without using a path in the header1 file ?

Edgar

[jorgon]

Hi Edgar

I'm sure you've looked at this from the GoAsm help file, but I refer to it for the sake of completeness:-

Syntax for #include
#include path\filename

path\filename can be either:-

a quoted string
a non-quoted string
a string in less-than and greater-than characters

GoAsm will look for the file using the path specified. If no path is specified it will look in the current directory. If the file is not found it will look for it in the path given by the INCLUDE environment string. You can set the INCLUDE environment string using the DOS SET command in the MS-DOS (command prompt) window, by calling the SetEnvironmentVariable API or using control panel, system, advanced, environment if your operating system will permit this. Note: there may be a different environment string for each folder or sub-folder. Ensure the environment string you wish to use is in the current directory.
You can nest #include files but it is good practice to avoid this as far as possible.

When GoAsm opens an include file, it does not change the current directory/folder.
To avoid naming the path in header1.h, you could do one of the following:-

• put header1.h in the current directory
• add the path of header1.h to the INCLUDE environment
• change the current directory to that containing header1.h (this could be done in a batch file, changed back afterwards if required, and you could force GoAsm to write its output to another directory using the /fo command)

[donkey]

Thanks Jeremy,

I did try the INCLUDE environment variable, setting it from the control panel without success, I will try to find the problem on my end.

Edgar

[jorgon]

Actually I just tried it and found that if you go through control panel, you need to reboot for the environment string to take effect.

[donkey]

Hi Jeremy,

Ah-ha thanks for your help. RadASM also does a good job of setting it for the GoAsm process (a feature which I forgot as it was added for HLA) so I used RadASM to set the environment variable when I build, works fine and it's not necessary to reboot.

Edgar

[jorgon]

I have had other queries about GoAsm's include search path, and I think I ought to add another step.  I just need to know what exactly that step should be.

The current search system for include files (if no path is specified) is:-

1. The current directory (folder).
2. The path given in the INCLUDE environment string.

If I were to add a step 3, this would not affect existing use because it would only be reached if the include file was not found in steps 1 and 2.
I think part of the problem is that the concept of the "current directory" is a little outdated.  It's only obvious to the user if GoAsm is started from the command line (DOS window).  If it is started from an IDE, then it could be anything - it is not necessarily where GoAsm.exe is situated, or where the first assembler source code file is situated.

The possibilities for step 3 seem to be:-

3a. The folder containing the first assembler source code file.

3b. The folder containing the first assembler source code file or, if different, the folder containing the include file currently being looked at.

3c. The folder containing the first assembler source code file or (if not found there) the folder containing the include file currently being looked at.

If we choose 3a, then project-specific include files would need to be contained in the same folder as the first assembler source code file.  If 3b, then project-specific include files could be in the same folder as the first assembler source code file, or they could be contained in a separate folder.  That separate folder would be specified by a path given for the first include file.  Other include files could then be specified by the first include file without giving a path.  So this would "trace" include files into that folder.  3c would permit either method with priority being given to the folder containing the first assembler source code file.