[Mono-dev] Resolving dependencies while compiling

[Jonathan Pryor]

On Wed, 2009-05-20 at 17:23 +0200, Grzegorz Sobanski wrote:
> I can sucessfully compile c.dll in VS if it only calls Met1, without
> referencing a.dll, and without having any copies of a.dll laying around.
...
> Unfortunately to compile c.dll in gmcs I need a a.dll even if c.dll
> does not use any type from a.dll.

This is because .NET doesn't use Reflection to generate assemblies (it
uses some C++ library + COM gunk), while gmcs currently uses
System.Reflection.Emit, and Reflection requires that all assemblies be
available for loading & resolution.

gmcs is currently being modified to use Mono.Cecil instead of
System.Reflection.Emit, which should make gmcs act more like .NET here.

> Now, some real-life example.
> We are building modular software and using a bunch of libraries, for
> example: Castle.MicroKernel, Castle.ActiveRecord, etc. (let's call them
> tier 1)
> They reference some more libaries. Iesi.Collections, NHibernate (tier 0)
> 
> We build modules (tier 2): ModuleA, ModuleB referencing and using a lot 
> of tier 1 libraries (Castle.* mainly).
> 
> And those modules are used by some applications (tier 3). Now even if 
> application is not using any types from Tier1 they are still needed
> at compile time (in mono, not in VS). What's more, even dlls from Tier0
> are needed.
> 
> There are different solutions we could use:
> 1) gmcs could compile like VS, not knowing the types from Tier0/1 -
>    ideal

This should eventually work with either Mono 2.6 or 2.8, due to the gmcs
Cecil migration.

> 2) reference all dll's from Tier0/1 in application - bad

Not sure why this is bad.  Annoying, certainly, but bad?

> 3) copy (symlink) all dll's from Tier0/1 to directory of every Module* (Tier2)
>    - that's what we've been using until now. But it started to be 
>      a real maintenance problem.

Someone off-list mentioned that svn + symlinks == pain, so I can see how
this would be problematic.

> 4) put all dll's from all Tiers to one directory - we want to avoid that

Not sure why you want to avoid this, considering that to _run_ your app
(for testing, etc.) you'll need all of these assemblies in the same
directory anyway (unless your test apps are so small that your tier 2
tests never make use of the tier 0 functionality, which just seems
strange to me).

> 5) use MONO_PATH= during compilation to show directories where Tier0/1
>    dll's can be found - we are using it now (I know it is 'not
>    recommended' :P)
> 6) use -lib instead of MONO_PATH - but that would still mean adding to
>    every project from Tier3 every directory from Tier0/1.

I also don't see how (6) is significantly different from (2).  I find
'-r:path/to/A.dll' (2) easier to understand than '-lib:path/to
-r:A.dll' (6), especially when more than one directory are involved, as
it makes explicit from which directory a file should be found in.
  
> To sum up - problem is when I'm using b.dll which has something
> from a.dll in it's public API, but I'm not consuming it. I would
> like to skip a reference to a.dll in c.dll then.
> 
> (We can ensure in some other way that all needed dll's from tier0/1 
> will be available at runtime).

What is this "some other way"?  MONO_PATH?

Why can't you reuse this "other way" for building?

 - Jon