[MonoDevelop] [PATCH. RFC] Absolute File References

["Andrés G. Aragoneses"]

Jerome Haltom wrote:
> 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

Are you sure?

Let's say you link to /usr/lib/whatever, in MD that should be a 
reference to ../../../(n times)/../usr/lib/whatever/.

Why not checking iteratively:
1) is .. == / ? If yes, it's absolute.
2) is ../.. == / ? If yes, it's absolute.
After n) It's relative.

The only case in which this would fail is that if someone stablishes 
it's root dir project to /, which is non-sense.

Regards,

	Andres

-- 



> 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