Re: C# support for automake

[Tim Van Holder]

Bruno Haible wrote:
>    Implementation | Compiler
>    ---------------+---------
>    pnet           | cscc
>    mono           | mcs
>    sscli          | csc

On Windows, it's the .NET SDK, and csc is the compiler.
If you're going to add support for C#, you should include its main
source platform.

> 
> Executables are run via a launcher program, whose name is again different:
> 
>    Implementation | Executor
>    ---------------+---------
>    pnet           | ilrun
>    mono           | mono
>    sscli          | clix (don't know for non-sscli versions)

On Windows, there is no launcher for executables - they're run directly.

> The object code generated from C# source code is platform-dependent.
> Although most (or all?) of the file format of C# libraries and executables
> is platform-independent, C# source code is processed by a preprocessor that
> understands #if conditionals. For this reason we must consider that object
> code generated for, say, x86_64, is different from object code generated for
> i586.

This sounds incorrect; by default, the compilers should produce IL
bytecode, which is supposed to be portable across platforms.  Only
native images will differ, but they're created by a separate step
(through the 'ngen' tool in the Windows case, not sure if the other
environments have a similar step available).
This is easily tested - I created a simple C# program, compiled it on
Linux using 'mcs -target:exe', and ran the result on Windows without a
hitch.  I would expect the same portability between pnet and mono.

> Object code libraries are files with suffix ".dll". They are installed
> under $prefix/lib.
> 
> Object code executables are files with suffix ".exe". There are two ways
> to install them:
>   a) Install the executable under $prefix/lib. Let the user invoke it through
>      an explicit "ilrun $prefix/lib/foo.exe" or "mono $prefix/lib/foo.exe".
>   b) Install the executable under $prefix/bin. Additionally install a one-line
>      invocation script $prefix/bin/foo:
>          #!/bin/sh
>          exec mono $prefix/bin/foo.exe "$@"
> I don't know which of these conventions should be preferred.

The second - it's an executable and belongs in bin; the wrapper script
is an extra step for those implementations that require a launcher.

> - A second kind of source files, called resources, files ending in
>   ".resources", can be embedded in object code libraries and executables.

These are typically created from .resx files, so it would not be
unreasonable for automake to include rules for them as well.
For the .NET SDK, the command is
        ResGen foo.resx foo.resources
or
        ResGen /compile foo.resx[,foo.resources] ...

> ====================== build-aux/csharpcomp.sh.in ======================
> [snip]
>     -L)
>       options_cscc="$options_cscc -L "`echo "$2" | sed -e "$sed_quote_subst"`
>       options_mcs="$options_mcs -L "`echo "$2" | sed -e "$sed_quote_subst"`

mcs supports the csc interface too; given that csc is the reference
implementation, it seems reasonable to prefer that option syntax for mcs
(so -lib: here and -reference:/-debug+ below).

>       options_csc="$options_csc -lib:"`echo "$2" | sed -e "$sed_quote_subst"`
>       shift
>       ;;
>     -l)
>       options_cscc="$options_cscc -l "`echo "$2" | sed -e "$sed_quote_subst"`
>       options_mcs="$options_mcs -r "`echo "$2" | sed -e "$sed_quote_subst"`
>       options_csc="$options_csc -reference:"`echo "$2" | sed -e 
> "$sed_quote_subst"`".dll"
>       shift
>       ;;
>     -g)
>       options_cscc="$options_cscc -g"
>       options_mcs="$options_mcs -g"
>       options_csc="$options_csc -debug+"
>       ;;
> [snip]
>
> Proposed actions in Makefile.in
> ===============================
> 
> [snip]
>
> 1) For the library:
>   - Target "all" should depend on foobar.dll.
>   - A target foobar.dll should be added:
> 
>       foobar.dll : module1.cs module2.cs libres.resources
>                $(CSHARPCOMP) $(CSHARPCOMPFLAGS) -o $@ $(srcdir)/module1.cs 
> $(srcdir)/module2.cs $(srcdir)/libres.resources
> 

If _SOURCES lists libres.resx instead of libres.resources, the
foobar.dll rule would remain as above, and an additional rule
is created for libres.resources:

        libres.resources: libres.resx
                $(RESXCOMP) -o $@ $(srcdir)/libres.resx

where RESXCOMP is another wrapper (not sure what tools Mono/PNet/SSCLI
provide).

>   - Target "clean" should remove foobar.dll.

And libres.resources if it was built from a resx file.