[nem-en] building with msbuild

[Kamil Skalski]

06-03-16, NoiseEHC <NoiseEHC at freemail.hu> napisał(a):
> Here is a patch (do not commit just try it out since it is not
> finished). BTW you can commit, will not break anything.

Ok, this seems good, feel free to commit (without LibrariesLoader.n
debugs of course).

>
> So I normally compile via MinGW then copy out.stage3/* and the
> tools/msbuild/* to /program files/nemerle.
> Then I can compile with build.cmd
> Finally if I copy bin/Debug to /program files/nemerle I can compile again :)

Great! So now we will have a way to build by MSBuild :)

> response... :( Another problem can be if you compile
> Nemerle.Compiler.dll and Nemerle.MsBuild.Tasks.dll
> with different Nemerle.dlls. I can assure you that it will not work... :)

That is fine. We should assume that Nemerle.Compiler and
MsBuild.Tasks.dll are always in sync - that thay use the same
Nemerle.dll.

>
> The remaining problem is that when I use NoStdMacros then it will not
> compile.
>     C:\MinGW\1.0\home\Administrator\nemerle\lib\tree.n(39,48,39,59):
> error : expecting identifier after `.'
>     C:\MinGW\1.0\home\Administrator\nemerle\lib\tree.n(57,25,57,36):
> error : expecting identifier after `.'
> I have no idea why... Clearly the compiler should not depend on
> Nemerle.Macros.dll didn't it?

It does. As you know Nemerle.Macros.dll defines most of the Nemerle's
syntax, so without it compiler does not even know what  'if (x) y else
z'  mean.
Now, Nemerle compiler is written in Nemerle, so in order to compile
itself, it must load existing Nemerle.Macros :)

If you use NoStdMacros option, then you must also manually load the
set of standard macros from some library, like by 
'-r:Nemerle.Macros.other.dll'  or '-m:Nemerle.Macros.other.dll'.

> With the patched compiler you can see that it always loads
> Nemerle.Macros.dll what can load a different
> Nemerle.dll with greedy loading -> the problem...

I think Nemerle.Macros is not a problem (it loads the same way with
and without greedy option). Probably it is just some conflict between
assembly that compiler is using for execution and the one it is using
for compilation.

>
> Another problem I noticed while digging in the compiler source is the
> special handling of System.Xml.dll.
> My advice is to ditch that.

Yes, it seems to be not needed. I will just remove the 'unless (greedy)' part.

>
> BTW why that greedy loading is necessary? Can we kill that?

This is for easy compilation from command line and to simplify what is
needed in build files. For example you can use:
ncc form.n -r System.Windows.Forms.dll

instead of
ncc form.n -r System.Windows.Forms.dll -r System.Data -r System.dll -r
System.Xml.dll

It is quite natural scenario, that if you reference some assembly A
and this assembly references some B, then you should also reference B.
So this option will make it automatic.

>
> Another question: why do you need the ability to use two different
> Nemerle.dll?

Because if we are compiling the Nemerle.Compiler.dll, then this
library should be compiled against the fresh Nemerle.dll, instead of
the one previously existing. So in this case we must force compiler to
load the fresh Nemerle.dll, instead of the default one.

It goes like this:
boot/ncc.exe  uses boot/Nemerle.dll to execute
now
boot/ncc.exe compiles sources of lib to  out.stage1/Nemerle.dll
boot/ncc.exe compiles sources of compiler to
out.state1/Nemerle.Compiler.dll (which should reference
out.stage1/Nemerle.dll, not boot/Nemerle.dll!!).


>
> > However I think there may be problems, if n.c.dll and n.m.dll use
> > different n.dll. That is I don't quite get why n.c.dll is linked to
> > different version of n.dll, than you're trying to link now.
>
> <- I am talking about that. Or is it just an example of the bug?
>

Well, bootstraping is in general a hard topic :)  You must carefully
track which library depends on which one and this is unfortunately
quite hard in environment like .NET, where libraries are loading
"automatically" ;)

--
Kamil Skalski
http://nazgul.omega.pl