using macro to %include file

[c051n3]

Hello folks,

I have defined the following macro to import (include) an .inc file into the source code.
PROJECTBASEDIR is an environment variable that contains the root path of my project.
For some reason when I run the macro it continually errors out with " '%include' expects a filename". I've been hacking on various incarnations of this for a while now and feel like I've hit a wall.

Here is the defined macro:

%macro import 0-*

   %if (%0!=1)
      %fatal "usage: import packagename"
   %endif

   %xdefine %$incfile %!PROJECTBASEDIR\%{1}\%{1}.inc
   %defstr %$incstr %$incfile
   ; %fatal "incstr =" %$incstr  <-- this prints out the correct path
   %include %$incstr
%endmacro

Can anyone point me in the right direction in trying to accomplish this 

[c051n3]

while looking for alternatives to this I came across this in the nasm manual:

4.6.4
Unlike the %include directive, package names for the %use directive do not require quotes, but quotes are permitted. In NASM 2.04 and 2.05 the unquoted form would be macro-expanded; this is no longer true.

Perhaps this is somehow related to my %include macro-expansion problem?

[Frank Kotler]

What Nasm version are you using? I ask because attempting to try out your file, Nasm was segfaulting on me. I've filed a bug report.

Making sure PROJECTBASEDIR actually existed got me past that. Changing '\'s to '/' (Linux doesn't like backslashes!) and pointing it to an .inc file that actually existed seemed to make it work. I did use a slash at the end of PROJECTBASEDIR... no, even without that it works... I just invoked it as "import foo"... and tried out a macro in "foo.inc"... seems to work.

What are you doing, exactly, that's getting this error? (I doubt if "%use" is relevant, but I could be wrong...)

Best,
Frank

[Frank Kotler]

Oh! I also added "%push" and "%pop" to keep Nasm complaining about the context-local variable "%$incfile", etc. Would that help you?

Code: [Select]

%macro import 0-*
   %push foo
   %if (%0!=1)
      %fatal "usage: import packagename"
   %endif

;   %xdefine %$incfile %!PROJECTBASEDIR\%{1}\%{1}.inc
   %xdefine %$incfile %!PROJECTBASEDIR/%{1}.inc
   %defstr %$incstr %$incfile
;    %fatal "incstr =" %$incstr  <-- this prints out the correct path
   %include %$incstr
   %pop
%endmacro

import foo
diz 1,2 ; crap from foo.inc

Best,
Frank

[c051n3]

Hello Frank,

Thanks for your reply.  I'm using nasm v2.09rc3 on Windows 7 64bit OS.
At first I thought maybe it was simply a case of 32 vs 64 bit issues so I compiled and built a new nasm executable using the source with Visual Studio 2005 and Microsofts Vista SDK using x64 target options. Same error.

Prior to using the macro I do %push a context to ensure I can use the context vars.
I've verified that PROJECTBASEDIR exists and the file to import exists.

You say it seems to work for you.  Are you able to verify that the filename parameter given to the macro truly gets included after the macro call? I cannot get to this point yet.

Thank you for helping with this!

[Frank Kotler]

Yeah... that "diz" macro is in "foo.inc", and is expanding to "mov ebx, 2" - (don't remember what it's supposed to be "for", but saw I had a "foo.inc" so I used it for a test case).

I won't be able to help you much. I'm not a very sophisticated macro user - I don't understand why you don't just do "%include 'myfile.inc'" and be done with it.

But I'll "try things" to see if I can figure out what the problem is. My thought was to put quotation marks around "%$incstr", but once I got it to quit segfaulting, and got Nasm to quit complaining about "empty context stack", it worked without it. If it complains about "empty context stack", I do get the "%include expects a filename" error, also. I guess "%defstr" gives you the effect of quote marks around the filename - never used that one before...

This is all with Linux (funky old kernel), and 32-bit, but that "shouldn't" matter to the macro processor... Hope you can get it working!

Best,
Frank

[c051n3]

Problem solved!

While trying the various ways to get it to work I had defined multiple context stacks and the PROJECTBASEDIR context var was actually contained in the parent context. Doh! 

Anyways, yes there is a segfault that occurs during %!ENV with this release when ENV is not found in the environment. I have tested this on both WinVista 32bit and Win7 64bit. I'm not sure if this behaviour exists in previous nasm releases tho...

Also, the 64bit version I created with VS2005 works great thus far! Thank you so much for separating out the perl gunk and distributing the prebuilt files.  That would require another tool in my toolchain. Warning to other MSVC developers:
  nmake cleaner /f mkfiles/msvc.mak will remove those prebuilt files! 

As to why I wanted this to work:
I'm not fond of dumping a zillion .inc or .h files in one directory not do I like one big include file. Thus for me maintaining multiple project directories under my main PROJECTBASEDIR allows me to include only what I want and need.
Thanks again 

[Frank Kotler]

Yeah, turns out the segfault has been there since 0.98.39, at least. Under active discussion on the nasm-devel mailing list right now, so it'll soon be gone, probably. Glad to hear you got it working. "solved" is good!

Best,
Frank

[Frank Kotler]

FWIW, that segfault is fixed! Further, our highly trained and efficient team of developers have added "%ifenv" (and friends), so we can check if an environment variable exists or not before attempting to use it, perhaps using a "default" if not...

Code: [Select]

%macro import 0-*
   %push
   %if (%0!=1)
      %fatal "usage: import packagename"
   %endif

;   %xdefine %$incfile %!PROJECTBASEDIR\%{1}\%{1}.inc

    %ifenv PROJECTBASEDIR
%xdefine %$incfile %!PROJECTBASEDIR/%{1}.inc
    %else
%xdefine %$incfile ~/nasmx/inc/linux/%{1}.inc
    %endif
   
   %defstr %$incstr %$incfile
;    %fatal "incstr =" %$incstr  <-- this prints out the correct path
   %include %$incstr
   %pop
%endmacro

import foo
diz 1,2 ; crap from foo.inc

Dunno if this would be useful or not, but it's available. Thanks to Cyrill Gorcunov, and to Bryant Keller for the documentation!

Best,
Frank

[c051n3]

That is excellent news indeed!  Thank you for the status update!

This new code to be added during a 2.09rc4 release? If so, I'll be testing it heavily as my projects now make extensive use of various environment variables.

[Frank Kotler]

Right. And available now in the lastest "snapshot":

http://www.nasm.us/pub/nasm/snapshots/latest/

Best,
Frank

[c051n3]

I tested nasm v2.09rc4 source built with VS2005 64bit and it appears to be fixed.
Thank you for making this happen 

[Cyrill Gorcunov]

Dunno if this would be useful or not, but it's available. Thanks to Cyrill Gorcunov, and to Bryant Keller for the documentation!

Best,
Frank

Yeah, thanks Bryant! (I was only committing this change into repo, Bryant wrote the docs