[build2] Interest in Development of NASM Module

[Boris Kolpackov]

Markus Pawellek <markus.pawellek at mailbox.org> writes:

> I am very interested in the development of a build2 module
> providing the possibility of compiling and linking NASM code.

Sounds doable. Not having used NASM myself, I've just tried it out on
the "Hello, World!" example from Wikipedia. I was even able to whip out
a toy buildfile that uses the new ad hoc recipes feature to build it:

using bin # For obje{}.

define asm: file
asm{*}: extension = asm

obje{*}: extension = o

exe{hello}: obje{hello}
{{
  diag ld $>
  ld -o $path($>) $path($<)
}}

obje{hello}: asm{hello}
{{
  diag nasm $<
  nasm -f elf64 -o $path($>) $path($<)
}}

To build on my Linux box I ran:

$ b config.bin.target=x86_64-linux-gnu


> For this, I have already taken a look inside the 
> libbuild2-hello and libbuild2-rust modules, 
> but the first one is not really explaining how to add 
> functionality and the second one is not compiling on my platform.

Hm, strange, was it perhaps due to the version mismatch? If so, could
you try it with the just-release 0.13.0?

Generally, libbuild2-rust is not a bad place to start. It's not too
complex but does something along the lines of what you want.


> Therefore I wanted to go even further and tried to understand
> the builtin cc, c, and cxx modules inside the build2 repository.
> But the code here was a little bit too much for me and hard to
> understand.

Yeah, that stuff is not for the faint of heart. Probably not the best
place to start.


> What would be the best starting point and  what would I have to do
> to get an overview of the build2 source code and to get an idea of
> build2 module development.

I think libbuild2-rust is a good starting point.


> Is there already an existing documentation concerning module development?

Unfortunately, at this stage the best documentation is existing modules
and the build system core headers (which are fairly well commented).


> Is it even reasonable to try to develop an external module for NASM, 
> would it be better to think about a builtin module, or would it even
> be better to not include it at all?

That's actually a good question. At the outset, let me state that I am
by no means an expert on assembler tooling and all I have is a general
idea of what's going on. So if some of the things I say below are wrong,
please do correct me.

Firstly, given the above example with ad hoc recipes, do we even need a
module? That's also a good question. I think the main reasons for wanting
the module would be:

1. Not having to repeat the recipes for multiple files/in multiple projects.

2. Automatic dealing with platform specifics (for example, translating
   x86_64-linux-gnu to -f elf64, etc).

3. Automatic include dependency extraction (%include directive, etc).
   
All of these are non-issues for simple projects and if ad hoc recipes are
all you need (at least for now), that's fine as well.

Now let's say you do want to write a module for NASM. So we are back to
the question of where it should go. We already have the bin module (short
for binutils) and we could add NASM support there.

I am not sure, however, this is the best approach. The bin module is
closely tied to the cc module and the plan is to automatically "derive"
the assembler and linker from the compiler being used (we already do this
on Window for the linker).

This is all a bit fuzzy to me since I don't have much experience with
using assemblers. I guess the question is whether it could be reasonable
to want to use both the C/C++ compiler's assembler (gas, MASM) and NASM
in different parts of the same build? If the answer is "yes" (and it feels
like it is), then I think it's best to have a separate module for NASM.

Here are a few other notes question that I've collected reading on NASM:

- Should we package NASM itself?

- OpenSSL requires NASM on Windows.

- NASM has the -M* option family for make-style dependency extraction.

- There is the %include directive and -i/-I search paths option.