nasm-devel — NASM development work

Re: [Nasm-devel] Fixed out of directory builds

[H. P. A. <hp...@zy...>]

On 04/14/17 07:23, Ed Beroset wrote:
> I noticed last night that an out-of-directory build of the latest git
> version of NASM did not work.  I usually create a subdir named "build"
> under the root and build things there.  The small attached patch fixes
> that issue.
> 
> Ed

Good catch.  Thanks, applied!

	-hpa

[Nasm-devel] Fixed out of directory builds

[Ed B. <be...@mi...>]

I noticed last night that an out-of-directory build of the latest git 
version of NASM did not work.  I usually create a subdir named "build" 
under the root and build things there.  The small attached patch fixes 
that issue.

Ed

Re: [Nasm-devel] On the future of the NASM documentation

[Ed B. <be...@mi...>]

H. Peter Anvin wrote:
> It is becoming pretty clear that maintaining our own typesetting
> system for the documentation is getting increasingly ridiculous.

I've not been active here for some time, but would heartily agree with that.

> Obviously we would have to make sure that the output not just looks
> right but has the proper metadata, which would mean using a stylized
> LaTeX, but that's not a problem -- it would still give us
> flexibility far beyond what we currently get.

Another possibility is markdown, although the processing might need to 
be somewhat customized.  The advantage is that it puts very little 
extraneous stuff into the human-edited input.

LaTeX has the advantage of a very long history and a plethora of tools.

Ed

[Nasm-devel] On the future of the NASM documentation

[H. P. A. <hp...@zy...>]

It is becoming pretty clear that maintaining our own typesetting system
for the documentation is getting increasingly ridiculous.  This is part
because Adobe is making the perhaps reasonable choice of not advancing
PostScript anymore and instead focusing on PDF ... but that also means
that the application rather than PostScript is responsible for layout.

I had to add support for OTF/TTF metrics to switch to better fonts, and
thoughts I'd add support for kerning at the same time, but quickly
learned that these days kerning has (reasonably) been merged into the
overall infrastructure for font shaping, which basically would imply
doing something with the equivalent complexity of Pango, and that is
just plain ridiculous.

Furthermore, the number of output formats that matter has dropped.  At
this point I believe the only ones that would realistically matter would
be (X)HTML Strict (so an external stylesheet can be applied) and PDF.
At the same time, TeX has grown up to support modern output formats
natively.

The NASM documentation is already written in a fairly TeX-like language,
and I'm genuinely wondering how hard it would be to convert it to LaTeX,
perhaps with extra macros.  That way we could use xelatex and htlatex to
produce PDF and HTML output, respectively.  Using xelatex rather than
the older pdflatex would among other things fully support Unicode.
Between texlive and MiKTeX these packages are readily available on all
the common desktop/development platforms.

Obviously we would have to make sure that the output not just looks
right but has the proper metadata, which would mean using a stylized
LaTeX, but that's not a problem -- it would still give us flexibility
far beyond what we currently get.

	-hpa

[Nasm-devel] nasm.us dead?

[Somchai S. <bur...@gm...>]

Is nasm.us being reinstalled or something?  It just gives an apache
error page now.  Cut & paste of the messages:

Service Unavailable

The server is temporarily unable to service your request due to
maintenance downtime or capacity problems. Please try again later.
Additionally, a 503 Service Unavailable error was encountered while
trying to use an ErrorDocument to handle the request.
-----------------
Apache/2.4.25 (Fedora) Server at www.nasm.us Port 80

[Nasm-devel] [PATCH] asm/parser.c -- Fix typo in testing for register

[Cyrill G. <gor...@gm...>]

It should be EXPR_UNKNOWN referred when testing
for register present.

A typo in 472a7c1d17e0212b3cbf5302a9f5cdb358be4425

https://bugzilla.nasm.us/show_bug.cgi?id=3392375

Signed-off-by: Cyrill Gorcunov <gor...@gm...>
---
 asm/parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/asm/parser.c b/asm/parser.c
index a20ef94..36a9a59 100644
--- a/asm/parser.c
+++ b/asm/parser.c
@@ -390,7 +390,7 @@ static int value_to_extop(expr * vect, extop *eop, int32_t myseg)
         if (!vect->value)       /* zero term, safe to ignore */
             continue;
 
-        if (vect->type < EXPR_SIMPLE)  /* false if a register is present */
+        if (vect->type < EXPR_UNKNOWN)  /* false if a register is present */
             return -1;
 
         if (vect->type == EXPR_UNKNOWN) /* something we can't resolve yet */
-- 
2.7.4

Re: [Nasm-devel] build failure

[H. P. A. <hp...@zy...>]

On 10/19/16 19:31, Dave Yeo wrote:
> On 10/17/16 10:43 PM, H. Peter Anvin wrote:
>> On 10/15/16 10:43, Andy Willis wrote:
>>> I had to make a change after the fseeko stuff was moved from file.c to
>>> nasmlib.h for off_t to be defined:
>>>
>>> diff --git a/include/nasmlib.h b/include/nasmlib.h
>>> index b1c490c..ab47f67 100644
>>> --- a/include/nasmlib.h
>>> +++ b/include/nasmlib.h
>>> @@ -45,6 +45,9 @@
>>>    #ifdef HAVE_STRINGS_H
>>>    # include <strings.h>
>>>    #endif
>>> +#ifdef HAVE_IO_H
>>> +# include <io.h>
>>> +#endif
>>>
>>>    /*
>>>     * tolower table -- avoids a function call on some platforms.
>>>
>>
>> Thanks!  Which compiler?
>>
> 
> I see the same issue,
> ...
> In file included from ./include/nasm.h:44:0,
>                   from asm/nasm.c:48:
> ./include/nasmlib.h:479:37: error: unknown type name 'off_t'
>   const void *nasm_map_file(FILE *fp, off_t start, off_t len);
> ...
> Both Andy and I are using GCC on OS/2, GCC 4.9.2 in my case.
> Davee
> 

Could you try the current git, or the latest daily build?

	-hpa

[Nasm-devel] Bug-fix

[Hilmar A. <hil...@gm...>]

Hi,

relating to the bug:
https://bugzilla.nasm.us/show_bug.cgi?id=3392325

I looked into the code for a bug-fix, it can be solved with one line added
in:
output/outelf.c
(at least on the master branch)

I attached the modified file, Peter Anvin told me to send in the bug-fix
per mailing-list, because I don't have push-permissions.

Kind regards,
Hilmar

Re: [Nasm-devel] build failure

[Dave Y. <dav...@gm...>]

On 10/17/16 10:43 PM, H. Peter Anvin wrote:
> On 10/15/16 10:43, Andy Willis wrote:
>> I had to make a change after the fseeko stuff was moved from file.c to
>> nasmlib.h for off_t to be defined:
>>
>> diff --git a/include/nasmlib.h b/include/nasmlib.h
>> index b1c490c..ab47f67 100644
>> --- a/include/nasmlib.h
>> +++ b/include/nasmlib.h
>> @@ -45,6 +45,9 @@
>>    #ifdef HAVE_STRINGS_H
>>    # include <strings.h>
>>    #endif
>> +#ifdef HAVE_IO_H
>> +# include <io.h>
>> +#endif
>>
>>    /*
>>     * tolower table -- avoids a function call on some platforms.
>>
>
> Thanks!  Which compiler?
>

I see the same issue,
...
In file included from ./include/nasm.h:44:0,
                  from asm/nasm.c:48:
./include/nasmlib.h:479:37: error: unknown type name 'off_t'
  const void *nasm_map_file(FILE *fp, off_t start, off_t len);
...
Both Andy and I are using GCC on OS/2, GCC 4.9.2 in my case.
Davee

Re: [Nasm-devel] build failure

[H. P. A. <hp...@zy...>]

On 10/15/16 10:43, Andy Willis wrote:
> I had to make a change after the fseeko stuff was moved from file.c to 
> nasmlib.h for off_t to be defined:
> 
> diff --git a/include/nasmlib.h b/include/nasmlib.h
> index b1c490c..ab47f67 100644
> --- a/include/nasmlib.h
> +++ b/include/nasmlib.h
> @@ -45,6 +45,9 @@
>   #ifdef HAVE_STRINGS_H
>   # include <strings.h>
>   #endif
> +#ifdef HAVE_IO_H
> +# include <io.h>
> +#endif
> 
>   /*
>    * tolower table -- avoids a function call on some platforms.
> 

Thanks!  Which compiler?

	-hpa

[Nasm-devel] build failure

[Andy W. <abw...@gm...>]

I had to make a change after the fseeko stuff was moved from file.c to 
nasmlib.h for off_t to be defined:

diff --git a/include/nasmlib.h b/include/nasmlib.h
index b1c490c..ab47f67 100644
--- a/include/nasmlib.h
+++ b/include/nasmlib.h
@@ -45,6 +45,9 @@
  #ifdef HAVE_STRINGS_H
  # include <strings.h>
  #endif
+#ifdef HAVE_IO_H
+# include <io.h>
+#endif

  /*
   * tolower table -- avoids a function call on some platforms.

Re: [Nasm-devel] clang patches

[H. P. A. <hp...@zy...>]

On 10/14/16 02:21, Daniel Lundqvist wrote:
>>
>> __has_attribute() sounds promising... do we have a presence test for that?
> 
> Yes, if __has_attribute is defined. Same mechanism for __has_feature.
> See http://clang.llvm.org/docs/LanguageExtensions.html#has-attribute and http://clang.llvm.org/docs/LanguageExtensions.html#has-feature-and-has-extension for
> typical usage.
> 

Looks like gcc has this feature too in gcc 5+, so for newer attributes
it would totally be the thing to use.  I have checked in a patch to that
effect.

	-hpa

Re: [Nasm-devel] clang patches

[Daniel L. <da...@ma...>]

> On 13 Oct 2016, at 23:07, hp...@zy... wrote:
> 
> On October 13, 2016 1:55:04 PM PDT, Daniel Lundqvist <da...@ma...> wrote:
>> 
>>> On 8 Oct 2016, at 06:35, H. Peter Anvin <hp...@zy...> wrote:
>>> 
>>> On 10/07/16 06:46, Daniel Lundqvist wrote:
>>>> 
>>>> Unfortunately clang does not realise that 'again' will never be
>> false
>>>> for non-glibc. How do you want that fixed? Is it OK to just
>>>> initialise f to NULL or do you prefer something else?
>>>> 
>>> 
>>> Setting f to NULL is fine.
>>> 
>>> From fd764d58a7ada29f5121e275ee6b1c050c5f219f Mon Sep 17 00:00:00
>> 2001
>>> From: Daniel Lundqvist <da...@ma...>
>>> Date: Fri, 7 Oct 2016 15:41:24 +0200
>>> Subject: [PATCH] include/compiler.h: Adapt 'malloc' attributes for
>> clang.
>>> 
>>> As clang does not support alloc_size attribute, don't try to use it.
>>> 
>>> Signed-off-by: Daniel Lundqvist <da...@ma...>
>>> 
>>> What happens if you do, given that it defined __GNUC__ and therefore
>>> claims to be compatible with gcc?
>>> 
>>> 	-hpa
>> 
>> It gives an 'unknown attribute' warning. IIRC, clang defining __GNUC__
>> does not mean 100% compatibility, rather it means gcc-like. I remember
>> reading about it, but can't find a source right now. I don't know how
>> viable it is to use __has_attribute, at least recent versions of both
>> gcc and clang support it.
> 
> __has_attribute() sounds promising... do we have a presence test for that?


Yes, if __has_attribute is defined. Same mechanism for __has_feature. See http://clang.llvm.org/docs/LanguageExtensions.html#has-attribute <http://clang.llvm.org/docs/LanguageExtensions.html#has-attribute> and http://clang.llvm.org/docs/LanguageExtensions.html#has-feature-and-has-extension <http://clang.llvm.org/docs/LanguageExtensions.html#has-feature-and-has-extension> for typical usage.

-- 
daniel

Re: [Nasm-devel] clang patches

[<hp...@zy...>]

On October 13, 2016 1:55:04 PM PDT, Daniel Lundqvist <da...@ma...> wrote:
>
>> On 8 Oct 2016, at 06:35, H. Peter Anvin <hp...@zy...> wrote:
>> 
>> On 10/07/16 06:46, Daniel Lundqvist wrote:
>>> 
>>> Unfortunately clang does not realise that 'again' will never be
>false
>>> for non-glibc. How do you want that fixed? Is it OK to just
>>> initialise f to NULL or do you prefer something else?
>>> 
>> 
>> Setting f to NULL is fine.
>> 
>> From fd764d58a7ada29f5121e275ee6b1c050c5f219f Mon Sep 17 00:00:00
>2001
>> From: Daniel Lundqvist <da...@ma...>
>> Date: Fri, 7 Oct 2016 15:41:24 +0200
>> Subject: [PATCH] include/compiler.h: Adapt 'malloc' attributes for
>clang.
>> 
>> As clang does not support alloc_size attribute, don't try to use it.
>> 
>> Signed-off-by: Daniel Lundqvist <da...@ma...>
>> 
>> What happens if you do, given that it defined __GNUC__ and therefore
>> claims to be compatible with gcc?
>> 
>> 	-hpa
>
>It gives an 'unknown attribute' warning. IIRC, clang defining __GNUC__
>does not mean 100% compatibility, rather it means gcc-like. I remember
>reading about it, but can't find a source right now. I don't know how
>viable it is to use __has_attribute, at least recent versions of both
>gcc and clang support it.

__has_attribute() sounds promising... do we have a presence test for that?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Nasm-devel] clang patches

[Daniel L. <da...@ma...>]

> On 8 Oct 2016, at 06:39, H. Peter Anvin <hp...@zy...> wrote:
> 
> On 10/07/16 21:35, H. Peter Anvin wrote:
>> 
>> What happens if you do, given that it defined __GNUC__ and therefore
>> claims to be compatible with gcc?
>> 
> 
> +#if defined(__clang__)
> +# define never_null __attribute__((returns_nonnull))
> +# define safe_alloc never_null __attribute__((malloc))
> +# define safe_malloc(s)
> +# define safe_malloc2(s1,s2)
> +# define safe_realloc(s)
> 
> The latter should be safe_alloc and never_null as appropriate, though,
> even if alloc_size() isn't defined.

Here is an updated patch, I somehow missed those uses. Thanks for catching that.

> Alternatively, we could define allocsize() as a macro... but that's
> probably more trouble than it's worth.

I opted for simplicity now. I suppose this can be changed later on if needed.

-- 
daniel

Re: [Nasm-devel] clang patches

[Daniel L. <da...@ma...>]

> On 8 Oct 2016, at 06:35, H. Peter Anvin <hp...@zy...> wrote:
> 
> On 10/07/16 06:46, Daniel Lundqvist wrote:
>> 
>> Unfortunately clang does not realise that 'again' will never be false
>> for non-glibc. How do you want that fixed? Is it OK to just
>> initialise f to NULL or do you prefer something else?
>> 
> 
> Setting f to NULL is fine.
> 
> From fd764d58a7ada29f5121e275ee6b1c050c5f219f Mon Sep 17 00:00:00 2001
> From: Daniel Lundqvist <da...@ma...>
> Date: Fri, 7 Oct 2016 15:41:24 +0200
> Subject: [PATCH] include/compiler.h: Adapt 'malloc' attributes for clang.
> 
> As clang does not support alloc_size attribute, don't try to use it.
> 
> Signed-off-by: Daniel Lundqvist <da...@ma...>
> 
> What happens if you do, given that it defined __GNUC__ and therefore
> claims to be compatible with gcc?
> 
> 	-hpa

It gives an 'unknown attribute' warning. IIRC, clang defining __GNUC__ does not mean 100% compatibility, rather it means gcc-like. I remember reading about it, but can't find a source right now. I don't know how viable it is to use __has_attribute, at least recent versions of both gcc and clang support it.

-- 
daniel

Re: [Nasm-devel] clang patches

[Daniel L. <da...@ma...>]

> On 8 Oct 2016, at 06:35, H. Peter Anvin <hp...@zy...> wrote:
> 
> On 10/07/16 06:46, Daniel Lundqvist wrote:
>> 
>> Unfortunately clang does not realise that 'again' will never be false
>> for non-glibc. How do you want that fixed? Is it OK to just
>> initialise f to NULL or do you prefer something else?
>> 
> 
> Setting f to NULL is fine.

Here is a patch for that.

-- 
daniel

Re: [Nasm-devel] clang patches

[H. P. A. <hp...@zy...>]

On 10/07/16 21:35, H. Peter Anvin wrote:
> 
> What happens if you do, given that it defined __GNUC__ and therefore
> claims to be compatible with gcc?
> 

+#if defined(__clang__)
+# define never_null __attribute__((returns_nonnull))
+# define safe_alloc never_null __attribute__((malloc))
+# define safe_malloc(s)
+# define safe_malloc2(s1,s2)
+# define safe_realloc(s)

The latter should be safe_alloc and never_null as appropriate, though,
even if alloc_size() isn't defined.

Alternatively, we could define allocsize() as a macro... but that's
probably more trouble than it's worth.

	-hpa

Re: [Nasm-devel] clang patches

[H. P. A. <hp...@zy...>]

On 10/07/16 06:46, Daniel Lundqvist wrote:
> 
> Unfortunately clang does not realise that 'again' will never be false
> for non-glibc. How do you want that fixed? Is it OK to just
> initialise f to NULL or do you prefer something else?
> 

Setting f to NULL is fine.


>From fd764d58a7ada29f5121e275ee6b1c050c5f219f Mon Sep 17 00:00:00 2001
From: Daniel Lundqvist <da...@ma...>
Date: Fri, 7 Oct 2016 15:41:24 +0200
Subject: [PATCH] include/compiler.h: Adapt 'malloc' attributes for clang.

As clang does not support alloc_size attribute, don't try to use it.

Signed-off-by: Daniel Lundqvist <da...@ma...>



What happens if you do, given that it defined __GNUC__ and therefore
claims to be compatible with gcc?

	-hpa

Re: [Nasm-devel] NASM 2.12.03rc1

[anonymous c. <nas...@us...>]

On 10/6/16, H. Peter Anvin <hp...@zy...> wrote:
> OK, I just fixed some bugs, mostly but not entirely related to
> dependencies.
>
> With those fixes, this works as expected in a fresh git clone:

thanks!

> ./autogen.sh
> ./configure --enable-werror
> make -j everything

the --enable-werror causes the build to fail on OS X:

./include/nasmlib.h:151:8: error: unknown attribute 'alloc_size'
ignored [-Werror,-Wunknown-attributes]

[several files throw this, for different line/char numbers]

> [omit "everything" if you don't have all the documentation tools installed.]

yeah, just make, then make everything gives me this:

$ make
[builds/succeeds]

$ make
cd rdoff && /Library/Developer/CommandLineTools/usr/bin/make all
make[1]: Nothing to be done for `all'.

$ make everything
cd rdoff && /Library/Developer/CommandLineTools/usr/bin/make all
make[1]: Nothing to be done for `all'.
false -b docbook -d manpage -o nasm.xml nasm.txt
make: *** [nasm.xml] Error 1

that's ok though

> The problems were limited to the master branch; nasm-2.12.xx was
> unaffected.  The above instructions work for that branch without any
> patches.

thanks!

[Nasm-devel] clang patches

[Daniel L. <da...@ma...>]

Hi,

With this patch, it almost builds with -Werror. Just the below left:

nasmlib/file.c:193:9: warning: variable 'f' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
    if (again)
        ^~~~~
nasmlib/file.c:196:10: note: uninitialized use occurs here
    if (!f && (flags & NF_FATAL))
         ^
nasmlib/file.c:193:5: note: remove the 'if' if its condition is always true
    if (again)
    ^~~~~~~~~~
nasmlib/file.c:179:12: note: initialize the variable 'f' to silence this warning
    FILE *f;
           ^
            = NULL
1 warning generated.

Unfortunately clang does not realise that 'again' will never be false for non-glibc. How do you want that fixed? Is it OK to just initialise f to NULL or do you prefer something else?

Re: [Nasm-devel] NASM 2.12.03rc1

[H. P. A. <hp...@zy...>]

OK, I just fixed some bugs, mostly but not entirely related to dependencies.

With those fixes, this works as expected in a fresh git clone:

./autogen.sh
./configure --enable-werror
make -j everything


[omit "everything" if you don't have all the documentation tools installed.]

The problems were limited to the master branch; nasm-2.12.xx was
unaffected.  The above instructions work for that branch without any
patches.

	-hpa

Re: [Nasm-devel] NASM 2.12.03rc1

[H. P. A. <hp...@zy...>]

On October 6, 2016 9:05:29 AM PDT, anonymous coward <nas...@us...> wrote:
>>>do the dependencies actually change frequently enough
>>>to warrant this overly complicated auto generation?
>>
>> Yes, they do... we had tons of problems with out of date
>dependencies.
>
>well... so far this auto-gen mechanism doesn't seem to fare any
>better...
>
>(my question was more along the lines of "how often does that structure
>of the source tree change nowadays, after the significant re-org?")
>
>fwiw, I also tried a build under Windows, but got this:
>
>[same steps as before, up until...]
>
>$ make aldeps
>perl -I./perllib -I. ./x86/insns.pl -b \
>        ./x86/insns.dat x86/insnsb.c
>Too many arguments for open at ./x86/insns.pl line 198, near "$oname)"
>Too many arguments for open at ./x86/insns.pl line 239, near "$oname)"
>Too many arguments for open at ./x86/insns.pl line 267, near "$oname)"
>Too many arguments for open at ./x86/insns.pl line 349, near "$oname)"
>Too many arguments for open at ./x86/insns.pl line 380, near "$oname)"
>Execution of ./x86/insns.pl aborted due to compilation errors.
>make: *** [x86/insnsb.c] Error 255
>
>happens to be a perl5 (5.0 patchlevel 5 subversion 03)
>
>as for next steps, can you give a build-after-fresh-git-fetch a try on
>your
>end, to see if it works for you?

Note that you don't need to run make alldeps yourself, but it should still work.

Perl 5.0 is *ancient*.  I suspect that there are Perl 5.8+ constructs that have made it into scripts by now, especially the 3-operand open().
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [Nasm-devel] NASM 2.12.03rc1

[anonymous c. <nas...@us...>]

>>do the dependencies actually change frequently enough
>>to warrant this overly complicated auto generation?
>
> Yes, they do... we had tons of problems with out of date dependencies.

well... so far this auto-gen mechanism doesn't seem to fare any better...

(my question was more along the lines of "how often does that structure
of the source tree change nowadays, after the significant re-org?")

fwiw, I also tried a build under Windows, but got this:

[same steps as before, up until...]

$ make aldeps
perl -I./perllib -I. ./x86/insns.pl -b \
        ./x86/insns.dat x86/insnsb.c
Too many arguments for open at ./x86/insns.pl line 198, near "$oname)"
Too many arguments for open at ./x86/insns.pl line 239, near "$oname)"
Too many arguments for open at ./x86/insns.pl line 267, near "$oname)"
Too many arguments for open at ./x86/insns.pl line 349, near "$oname)"
Too many arguments for open at ./x86/insns.pl line 380, near "$oname)"
Execution of ./x86/insns.pl aborted due to compilation errors.
make: *** [x86/insnsb.c] Error 255

happens to be a perl5 (5.0 patchlevel 5 subversion 03)

as for next steps, can you give a build-after-fresh-git-fetch a try on your
end, to see if it works for you?

Re: [Nasm-devel] NASM 2.12.03rc1

[H. P. A. <hp...@zy...>]

On October 5, 2016 9:44:57 PM PDT, anonymous coward <nas...@us...> wrote:
>On 10/4/16, H. Peter Anvin <hp...@zy...> wrote:
>> Hi all,
>>
>> I have tagged a NASM 2.12.03rc1.  I hope to get a 2.12.03 out as soon
>as
>> possible.  Please let me know if there is anything missing, or
>broken.
>
>build fails on OS X as follows:
>
>[starting from a blank slate]
>
>$ git clone git://repo.or.cz/nasm.git nasm
>
>$ cd nasm
>
>$ sh autogen.sh
>
>$ sh configure
>
>$ make alldeps
>[...]
>tools/mkdep.pl: cannot determine path for dependency:
>include/compiler.h -> config/config.h
>make: *** [alldeps] Error 25
>
>$ make
>make: *** No rule to make target `config.h', needed by `asm/nasm.o'. 
>Stop.
>
>$ ls config/
>config.h	config.h.in	msvc.h		unknown.h
>
>$ ls include/
>compiler.h	hashtbl.h	insns.h		md5.h		nasmint.h	opflags.h	rbtree.h	saa.h		tables.h
>disp8.h		iflag.h		labels.h	nasm.h		nasmlib.h	raa.h		rdoff.h		strlist.h	ver.h
>
>do the dependencies actually change frequently enough
>to warrant this overly complicated auto generation?

Yes, they do... we had tons of problems with out of date dependencies.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.