lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tidies binary relocation (issue 6463066)


From: Graham Percival
Subject: Re: Tidies binary relocation (issue 6463066)
Date: Sun, 19 Aug 2012 14:15:48 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Aug 19, 2012 at 10:27:37AM +0100, Phil Holmes wrote:
> ----- Original Message ----- From: "Graham Percival"
> <address@hidden>
> To: "Phil Holmes" <address@hidden>
> >OTOH, I don't think that we should delete bits of code unless we
> >know why they were there in the first place.  There's just so many
> >dark corners of lilypond that no active developers are familiar
> >with.
> 
> I think we should do some sweeping up in cobwebby corners, if we
> can.  In particular, when we can't find any reason for the code to
> be there in the first place.  I've not worked out yet how to get git
> to show which commit put that code in.  If someone could either do
> that, or explain how to, I think it could help.

gitk lily/relocate.cc lily/include/relocate.hh

you can list as many (or as few) files as you want to get only the
history specific to those file(s).  Adding an entire directory
will give you everything for all files in that directory (and
subdirectories).

> >I'm not saying that I'm completely opposed to having this in git
> >master.  I'd feel better if you made some binaries and asked users
> >to test them first.  But even without that, as long as you'll be
> >around in Sep to revert this patch if necessary, I think it could
> >still go forward.
> 
> I've made binaries and tested them under Ubuntu.  The code is not
> windows specific, it's OS independent.  It relies on someone setting
> the environment value LILYPOND_RELOCATE_PREFIX which could work on
> any OS.

Yes, but that environment variable could be set up by the OSX .app
or the windows installer.  I agree that in this case it seems
unlikely since we haven't found that string in the lilypad or gub
repositories, though.  But I wanted to note that environment
variables don't require the user to set them up specifically.

>  So I think the only way to get enough people to test would
> be to put it into a release and see if anyone complains.  I would
> revert in that case.

There *is* another way: build binaries, upload to your server,
email -user asking for volunteers to test them.  I used to do this
quite a bit when I was working on GUB back in Fall 2009.  Yes,
it's more work, but OTOH it meant that I wasn't treating git
master as an testing ground.  The lilypond developer community is
getting pickier about only putting patches into master if there's
evidence that they do no harm -- that's the whole point of the
reviews and Patchy.  When it comes to build system stuff,
unfortunately there's no way to test it on a single platform.

That said, don't take this as a vote against the patch.  I'm ok
with it going through.

- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]