[MonoDevelop] [PATCH. RFC] Absolute File References

[Jerome Haltom]

inline

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.

Well, the problem is, at some points, the strings are passed to classes
which do not have a reference to the ProjectReference, thus they cannot
check IsAbsolutePath. This happens in the Project itself. The project
exposes GetReferenceDeployFiles, which returns strings. There is no way
for a user of Project to determine whether these strings should be
stored as absolute or not. Something has to relay that information.
ProjectDeployFile was what I chose to call my solution. I do agree it
needs to be renamed, and will take suggestions as to it's appropriate
name. ProjectReferencePath or something seems better.

>       * AbsolutePath is a bad name for a boolean property. Something
>         like IsAbsolutePath would be better.

I agree with this. I waffled between the two for awhile, but eventually
took the Is off because some other properties did not have it.

>       * Don't convert to absolute path in the getter of
>         ProjectReference.Reference. It should be done when
>         deserializing.

This is what my first attempt was like, and it became unwieldy, but I
now forget why. I think it had something to do with then being forced to
convert the Reference back and forth in the setter to IsAbsolutePath,
and then to base the getter on Path.IsRooted. I'll re-explore the
option.

> It just became a 
> 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
>