[MonoDevelop] [PATCH. RFC] Absolute File References

["Andrés G. Aragoneses"]

Andrés G. Aragoneses wrote:
> 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.

Hugh, and it would fail also if the project's root dir is in the same 
first-level dir from root as the library, which is maybe not nonsense, 
but totally uncommon...

Regards,

		Andres

--