Hi Bram :)
* Bram Moolenaar <[EMAIL PROTECTED]> dixit:
> DervishD wrote:
>
> > I mean, that's not the point. The point is that the source code is
> > using hardcoded directories, and that is not a good practice, even if
> > you force to have all runtime files under the same directory, because
> > someone could change one of the many variables under "src/Makefile" and
> > have the files installed in a place where the source code (which doesn't
> > use those variables) won't be able to find them.
>
> OK, so we should remove the variables from Makefile, so that nobody is
> tempted to change them.
Yes. Avoiding the risk, so to say.
> It's mostly OK to hardcode the directory names in the source code, since
> they can't be changed without causing lots of trouble.
Well, in Vim's case, yes. Otherwise, hardcoding thing is, IMHO, not
a very good practice. I've modified other's code a couple of times and
hardcoded paths were a pain in the a*s.
> > > If you really want to do it differently you are on your own. It's
> > > good that this is difficult, so that people who are causing problems
> > > for users will have to work hard to do that.
> >
> > I don't see how getting rid of hardcoded directories in the source
> > code is going to cause problems for users ;) In fact, hardcoded
> > directories may cause problems: if you modify "src/Makefile" and don't
> > reflect those changes in the source, for example. Of course, end users
> > shouldn't modify things under "src/Makefile" if they're marked as "DON'T
> > MODIFY THIS", but they don't have to work hard to do that and it will
> > cause problems.
>
> The warning is there:
>
> ### Location of Vim files (should not need to be changed, and
> ### some things might not work when they are changed!)
My first though when I saw that warning was "well, I'm supposed not
to change this to fit files in my hierarchy, but the fact is that I can,
and the Makefile is organized so changing these kind of variables move
files around, like VIMRTLOC, so...". Given that you *must* change some
of these variables in order to place runtime files in a non-default
place, changing the rest is tempting if you need to move files around,
and looking at the code to see which ones you can touch and which ones
must remain intact is the hard job. Changing them is the non-hard job,
and the errors that will appear not always are easy to connect to the
modifications in the Makefile.
> > If you don't want the hardcoded dirs removed (and that's your
> > design, so I respect that), then how about getting rid of variables in
> > the "*SUBDIR" and "*SUBLOC" families? This way is not hard, but
> > IMPOSSIBLE to break things even using the hardcoded directories :)
> >
> > The change is amazingly simple and makes sense: SUBDIR variables are
> > only used by SUBLOC variables, and those in turn are only used in the
> > DEST_ variables, which make use of DESTDIR. A simple substitution will
> > avoid risks and then users will *really* have to work harder to break
> > things. And that includes annoying users like me ;)))
> >
> > I think this is a good idea (much less intrusive than that of
> > modifying the source code) but hey, I'm not going to argue with you
> > because I *really* love vim like it is now and I consider your work an
> > amazing piece of code: elegant, easy to follow and does its job
> > amazingly good. I'm not licking your arse ;), it's really what I think
> > of vim. Consider the issue just a suggestion from a fan ;)
>
> Mostly this can be done. Cleans it up quite a bit. Only reason I can
> think of to keep the variables is to avoid confusion about using the
> name for something else than the subdirectory name.
If you want me to, I can prepare a patch (agains 7.0.188) for the
Makefile, and you can see if you like it.
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
