[MonoDevelop] [PATCH. RFC] Absolute File References

[Jerome Haltom]

I have updated my patch against trunk today. I have attached it here.


On Wed, 2008-05-14 at 17:17 +0200, Lluis Sanchez Gual wrote:
> The patch looks ok. Some comments:
> 
>       * I don't see the need for the class ProjectDeployFile. We can
>         assume that if a project reference has the AbsolutePath flag
>         set, all files returned by GetReferencedFileNames are absolute.
>       * AbsolutePath is a bad name for a boolean property. Something
>         like IsAbsolutePath would be better.
>       * Don't convert to absolute path in the getter of
>         ProjectReference.Reference. It should be done when
>         deserializing.
> 
> Lluis.
> 
> 
> El dj 08 de 05 del 2008 a les 12:42 -0500, en/na Jerome Haltom va
> escriure:
> > 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.
> > 
> > 
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mdrelativepatch.diff
Type: text/x-patch
Size: 39698 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/monodevelop-list/attachments/20080619/faed668c/attachment-0001.bin