[MonoDevelop] [PATCH. RFC] Absolute File References
Jerome Haltom
wasabi at larvalstage.net
Thu May 8 15:40:08 EDT 2008
This is interesting, but probably way more complicated than is required.
In my patch, the user just has to check a check box on the reference for
Absolute Path. In yours he's responsible for typing in the path to the
reference, or hand editing it to either remove ${ProjectDir} or add it.
Maybe it should always automatically be added, unless the user hand
edits it out? It changes the interface of the References property box
quite a bit. It also requires a breaking change in the .mdp file format:
new files will begin to have variables in them, old versions of MD won't
support that.
I don't think it'd go over very well.
That said, I do like the ability to hand type reference paths... for
instance when the reference is built as the output of another project
from some custom process: for instance running ikvmc to convert a .jar
to a .dll.
My desire for that is out of the scope of this though.
On Thu, 2008-05-08 at 14:12 -0500, Marcos Marín wrote:
> 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
>
>
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
More information about the Monodevelop-list
mailing list