Yes, we shouldn't have any .cs files that are not included in any .csproj. I
would be surprised if there were too many of them but there might be some. Feel
free to send a patch that deletes them.
Microsoft.Scripting.Core directory includes DLR v1.0 that shipped in .NET 4.0
in System.Core. We s
As ive already mentioned there are currently (within Runtime at least) a large
number of *.cs files that are not included in any csproj files. These files
seem
to implement classes that already exist within System.* dll's.
There also seem to be some *Build*csproj files. Are these maintained?
MSBuild is a pretty powerful build language, other than being ugly as
sin I don't see any reason why xbuild shouldn't be the way to go on
linux platforms. *shrugs* Just my two copper.
On Thu, Nov 4, 2010 at 4:07 AM, Tomas Matousek
wrote:
> "Mainly the complete and easy separation of dlr from ir
"Mainly the complete and easy separation of dlr from ironruby"
I don't think we need cmake to make this happen. In fact, I don't even think it
is desirable to do so (at least not short term). I'm still convinced that
having all source code in a single repo (perhaps split into multiple
submodule
I should also add that im going to continue because
1) I want to learn more cmake
2) there is also the possiblity to generate cmake files from csproj files :)
> > Please don't add yet another build system.
> >
> > Generating .csproj files is not the right way to go. The project files
> > are
> Please don't add yet another build system.
>
> Generating .csproj files is not the right way to go. The project files are
> and should be the primary metadata storage for the build system. If you
> work in VS and add a new file VS will add it into csproj.
It can [1] be automatically available t
