[Mono-dev] Resolving dependencies while compiling
jonpryor at vt.edu
Wed May 20 12:21:17 EDT 2009
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 -
This should eventually work with either Mono 2.6 or 2.8, due to the gmcs
> 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?
More information about the Mono-devel-list