[MonoDevelop] [PATCH. RFC] Absolute File References

[Jerome Haltom]

Howdy. The last few days I've been working on a patch to MonoDevelop to
implement a feature I consider pretty important on the Linux/Unix space.
I'm going to start by explaining the problem, then my solution.

First the problem. Sometimes it is understandable that in closed source
shops that use Visual Studio, when only a few developers are working on
it, a reference might be added to a third party assembly that exists on
a shared network drive. In VS, you'd right click on your project and
choose Add Reference, Browse, navigate to your shared network drive, and
choose the assembly. VS would store the absolute path to the assembly in
the project file, so that other users would attempt to refer to the
assembly from the same location.

In open source code, this is generally a poor idea, for obvious reasons.
Nobody has shared network drives. For closed source internal company
code, there is nothing wrong with this. It's perfectly fine, many people
do it, and it works as expected.

Another situation might be when you want to add a reference to a library
installed on your OS, but which provides no means of dynamic location of
the assembly. Perhaps the assembly is simply installed directly
into /usr/lib. Perhaps it was never really packaged properly to be
consumed by others. No pkgconfig files. I personally see nothing wrong
with this. It would be nice to modify the package so that it installed a
pkgconfig file, no doubt. But you aren't going to convince my small
internal IT department to do so. Suggesting that we do is a non-starter.

All of those points considered, MonoDevelop does not allow this to work.
If you add a reference to a file in /usr/lib, for instance, MonoDevelop
stores in it's project file something along the lines of
'../../../../../../usr/lib/foo/Bar.dll'. This is silly. There is no
expectation that my project file will be in the same place on every
system, so no expectation that the relative path will be the same. It
breaks.

So. There are a few possible ways to address this that I see.

a) Advocate that nobody refers to files outside of the solution
directory, and anybody who does is doing it Wrong.

I don't really find this solution practical. You won't convince people
by mandating solutions like this. Additionally, I don't really even have
a ethical problem with references outside my project directory! There is
no consistent definition of Wrong here.

b) Store absolute paths in the project file when appropriate.

I'm all for this. If there was a way that would automatically determine
when a file should be stored absolute. I don't think there is a way. You
can say if it's in a level above the solution file... but I've had
solution files deep in my source hierarchy before, so that won't work.

I want to note that this is not a real problem on Windows. Windows has a
very obvious way to determine if a path should be absolute or relative:
a drive or share name. It's obvious. In Unix, with out single root,
things are less clear.

c) Allow the user to choose whether the path is absolute or not.

On the face of it, I don't like asking the user to choose this. But
after considering the other solutions above, I'm not sure of any other
choice. For a given reference, simply make it a property whether or not
the reference is "absolute" or not. User checks or unchecks it. The job
is done.

I'm all for c! Being all for c), I wrote it. Attached is a patch that
implements c).

Currently the Project class defines GetReferencedFileNames, which
returns as a list of absolute paths to assemblies that should be
included when compiling the project. I have altered this to
GetReferencedFiles which return type ProjectDeployFile.
ProjectDeployFile is a new type that contains both an absolute path, and
an indicator on whether or not the path should be persisted absolute.
This allows components, such as the Autotools generator, to refer to the
path, and also make a decision about whether or not to convert it to
relative when storing it in a Makefile.am.

I think ProjectDeployFile should be renamed, to something like
ProjectReferenceFile, or ProjectFileReference... but both of these
conflict semantically with existing names, so I left it what it is. Feel
free to change it or suggest alternatives.

The ProjectReference class has grown a property AbsolutePath, which
indicates whether an absolute path should be used. This property is not
serialized to the project file. It's inferred based on the content of
the project file. If the project file contains /Foo, then it is
absolute. If it contains Foo, or ../Foo, then it is not. The getter and
setter for this property alter the actual stored reference itself. I
think this is perfectly intuitive, and it does not alter the project
file definition any.

The Autotools generator has been modified to make use of the information
on DeployFile to decide whether to store an absolute path to a relative
path in the generated Makefiles.

I changed all code I could find that used GetReferencedFileNames.

Please review the patch, and offer any comments. I've already talked
with a few people... many of whom were pro, after my rationalization,
and some who were con for reason a). I'd hope any discussion persuades
the dissenters to change their mind.

Thanks for your time.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mdrelativepatch.diff
Type: text/x-patch
Size: 44711 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/monodevelop-list/attachments/20080508/dcbb5dff/attachment-0001.bin