SCons
SCons 0.96.93 with C# support
This issue was originally created at: 2009-09-23 21:58:06.
This issue was reported by: damienhocking.
damienhocking said at 2009-09-23 21:58:06
Hi all,
as per the mailing list, here's SCons 0.96.3 with C# support added. It worked for .Net 2.0 and Mono. The main tools are in csc.py for Windows and gmcs.py for Linux. Not tested on any other *nix.
I can try and help if there are any issues.
Damien
damienhocking said at 2009-09-23 22:01:15 Created an attachment (id=633) 0.96.93 with C# support
garyo said at 2009-11-30 19:07:22
Hi Damien; it would be really helpful if you could send a diff rather than (or in addition to) the whole source tree. Would make it easier for us to see what you added and the scope of the changes. Thanks!
damienhocking said at 2009-12-15 13:25:23
I had an email conversation with Greg Noel today. He suggested I post one of my emails here to help the process:
Looking at the code again, there's src/engine/SCons/Tool/csc.py for Win32 and src/engine/SCons/Tool/gmcs.py for Linux/POSIX. There's the two entries for those in src/engine/Manifest.in, and a modification to other_tools in src/engine/SCons/Tool/__init__.py for gmcs and csc.
other_tools = FindAllTools(
[
"BitKeeper",
"csc",
"CVS",
"dmd",
"dvipdf",
"dvips",
"gmcs",
"gs",
"jar",
"javac",
"javah",
"latex",
"lex",
"m4",
"midl",
"msvs",
"pdflatex",
"pdftex",
"Perforce",
"RCS",
"rmic",
"rpcgen",
"SCCS",
# 'Subversion',
"swig",
"tar",
"tex",
"yacc",
"zip",
],
env,
)
I can't remember why I didn't put that into the tool_list for each platform. I think it might have been because I couldn't work out how to add a new compiler category (c_compilers, cxx_compilers, cs_compilers etc) for each platform and make it all work. I see in the latest code that there's Java builders where there weren't any in the 0.96 code, so perhaps that needs to be added. There might need to be some work to integrate it with the new MS-specific tool setup as well.
I can also put a couple of simple tests together.
stevenknight said at 2009-12-15 17:12:43
SK to research and prioritize, bug party triage suggests 2.1 / 2.x p3
stevenknight said at 2009-12-15 18:06:34
Actually put SK's name on it...
stevenknight said at 2009-12-15 18:08:46
SK should be the assignee, not the QA contact...
stevenknight said at 2009-12-28 11:22:33 Created an attachment (id=671)
Refactored patch with test cases
stevenknight said at 2009-12-28 11:32:33
Based on initial assessment and some preliminary work, I'm prioritizing this 2.x P3.
I've uploaded a patch with my current state of things. It refactors the common settings in {csc, gmcs}.py into a csharp.py module, and the lets the two tool-specific modules only worry about setting the actual $CSC variable.
I added rudimentary test cases, largely cribbed from test/CC/*.py tests and some quick googling for "Hello, world!" patterns in C#. They pass, but only test executables, not library builds.
I would have made this 2.1 P3, except there's a user interface issue that I think should be solved. The original code and my refactoring both add new CLIProgram() and CLILibrary() builders. I think it'd be simpler for the user if somehow the Program() and SharedLibrary() builders could just accept .cs files as input. Unfortunately, this runs into an area where our architecture kind of sucks, because the Program() builder basically assumes that every input is an object file to be fed to a linker.
I'm planning to experiment a bit with different ways to accomplish this, most of which would basically boil down to treating the C# compiler like a linker. Worst case, it might involve turning the Program() builder into a pseudo-builder that's smart about examining its input file types, but that would undoubtedly have a lot of ripple effects and would argue for using the separate CLIProgram() builder as-is.
In the meantime, I wanted to capture my patch here and invite comments/help.
russel said at 2010-03-04 11:17:14
I should have looked at this issue before starting to do something with the materials from the wiki page myself. I have started a Bazaar branch of a package version of this tool to avoid having to amend the main SCons codebase. lp:~russel/sconsaddons/csharp is the branch on Launchpad.
I was intending to have just a single tool to cover both Mono and Microsoft C#. The user code is the same, why should they have to worry about platform dependency of the tool chain. Or is this the wrong thought train?
I guess we need to find a way of getting the tests into the package and an infrastructure to run them. This is trying to work out a paradigm for testable tools not embedded in the main SCons codebase.
russel said at 2010-03-04 11:20:46
I wonder if the analogy here for C# is with Java rather than C/C++/Fortran. The compilation products of a C# compilation are a set of compiled bytecode files (assemblies) not a single executable or shared object.
There is also a connection with Erlang and its beam files.
Perhaps then the "super architecture" is those languages that generate a single executable as a result of compilation compared to those that create a collection of things that are not linked.
russel said at 2012-09-13 22:54:49
For the record, the C# tool has moved from Bazaar/Launchpad to Mercurial/Bitbucket: https://bitbucket.org/russel/scons_csharp
damienhocking attached scons-src-0.96.93.tar.gz at 2009-09-23 22:01:15.
0.96.93 with C# support
stevenknight attached issue-2490-1.patch at 2009-12-28 11:22:32.
refactored patch with test cases
There's a C# tool in scons-contrib. Do we know if that supersedes this, or vice versa? Does this issue need to remain open?
contrib version was last updated 2 years ago.. so It probably supersedes this
I pulled up one of the files and did a git blame there and it showed russell 2 years ago.. so I think so.