[MonoDevelop] [PATCH. RFC] Absolute File References

[Marcos Marín]

This is what I do in the CBinding:
All paths are absolute, but paths get parsed for vars like ${ProjectDir} and
${CombineDir}, so if I want to link a lib in /usr/lib/somelib.so thats fine,
yet I can also add a reference to something that comes packaged with the
project like ${ProjectDir}/libmymath.so which will work perfectly fine on
someone else's computer.

Take a look at the StringParserService
http://anonsvn.mono-project.com/viewcvs/trunk/monodevelop/main/src/core/MonoDevelop.Core/MonoDevelop.Core/StringParserService.cs?view=markup
and this is an example of the widgets we use to allow the user to add a var
like ${ProjectDir}.
http://anonsvn.mono-project.com/viewcvs/trunk/monodevelop/main/src/addins/CBinding/Gui/CodeGenerationPanel.cs?view=markup

On Thu, May 8, 2008 at 1:22 PM, "Andrés G. Aragoneses" <knocte at gmail.com>
wrote:

> 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
>
> --
>
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20080508/661c11b5/attachment.html