Hi Bruno,
Just a few quick remarks from a glance.
* Bruno Haible wrote on Mon, Dec 05, 2005 at 01:02:10PM CET:
>
> 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.
>
> Object code libraries are files with suffix ".dll". They are installed
> under $prefix/lib.
Is it reasonable to assume that programs will link against these
libraries, which are
- not built in the same package as the dll, or
- which do not contain C# code, and are not built or run with one of the
tools below?
> Here is the compiler wrapper:
>
> ====================== build-aux/csharpcomp.sh.in ======================
> func_tmpdir ()
> {
> # Use the environment variable TMPDIR, falling back to /tmp. This allows
> # users to specify a different temporary directory, for example, if their
> # /tmp is filled up or too small.
> : ${TMPDIR=/tmp}
> {
> # Use the mktemp program if available. If not available, hide the error
> # message.
> tmp=`(umask 077 && mktemp -d -q "$TMPDIR/gtXXXXXX") 2>/dev/null` &&
Probably a good idea to change `gt' into `cs' or something else a bit
better recognizable.
> test -n "$tmp" && test -d "$tmp"
> } ||
> {
> # Use a simple mkdir command. It is guaranteed to fail if the directory
> # already exists. $RANDOM is bash specific and expands to empty in shells
> # other than bash, ksh and zsh. Its use does not increase security;
> # rather, it minimizes the probability of failure in a very cluttered /tmp
> # directory.
> tmp=$TMPDIR/gt$$-$RANDOM
Ditto.
> (umask 077 && mkdir "$tmp")
> } ||
> {
> echo "$0: cannot create a temporary directory in $TMPDIR" >&2
> { (exit 1); exit 1; }
> }
> }
> sed_quote_subst='s/\([|&;<>()$`"'"'"'*?[#~=% \\]\)/\\\1/g'
If you encounter options with backslashes frequently (even on non-w32
hosts), you may want to parameterize use of echo. Probably nowadays
one of `echo', `print -r -' or `printf %s\n' will do.
> options_cscc=
> options_mcs=
> options_csc="-nologo"
> sources=
> while test $# != 0; do
I'd use `-ne' here.
> case "$1" in
No quotes necessary here.
> -o)
> case "$2" in
Ditto.
> *.dll)
> options_cscc="$options_cscc -shared"
> options_mcs="$options_mcs -target:library"
> options_csc="$options_csc -target:library"
> ;;
> *.exe)
> options_csc="$options_csc -target:exe"
> ;;
*snip*
> Proposed actions in Makefile.in
> ===============================
> 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
You'd probably also want AM_CSHARPCOMPFLAGS, for consistency
(and to allow the package author to set options).
> - Target "clean" should remove foobar.dll.
> - Target "install" should install foobar.dll into $(libdir), using
> $(INSTALL_DATA).
May any post-install action be necessary for the library (on some hosts)?
How does the installed program find its libraries?
How the uninstalled?
> - Target "uninstall" and "installdirs" accordingly.
>
> 2) For the executable.
> - Target "all" should depend on proggie.exe.
> - A target "proggie.exe" should be added:
>
> proggie.exe : main1.cs main2.cs mainres.resources foobar.dll
> $(CSHARPCOMP) $(CSHARPCOMPFLAGS) -o $@ $(srcdir)/main1.cs
> $(srcdir)/main2.cs $(srcdir)/mainres.resources -lfoobar
> - Target "clean" should remove proggie.exe.
> - Target "install" should install proggie.exe into $(bindir), using
> $(INSTALL_DATA). (Not using $(INSTALL_PROGRAM), because INSTALL_PROGRAM
> sometimes contains an "-s" options, instructing 'install' to invoke
> 'strip' - which does not make sense here.)
> Optionally (or always?), on platforms where $EXEEXT is not ".exe",
> also install a script 'foobar' into the same directory, using
> $(INSTALL_SCRIPT), that invokes proggie.exe via the interpreter found
> by AM_CSHARPEXEC_OPTIONAL.
Should the proggie script also be created for the uninstalled
executable?
Cheers,
Ralf
