Upgrade safety question
Status: Beta
Brought to you by:
worden
In order to do seamless upgrades from the old to the new WW on the theobio farm, we need to know how the old WW's prerequisite projects are handled by the new WW. They don't have the variable name recorded explicitly, right? So does it give them the right default variable name?
Anonymous
I've just done some checking on the old WW - I tried manually adding "project-dir-var="NAME"' to the project description, but unfortunately when WW updates the project description it removes the attribute (it's only understood by the new WW).
So the upgrade path doesn't include setting those before upgrading the software, at least not if we want it to be there reliably. I could change the old WW, but I don't think it's necessary. I think the path is this:
For instance for a project that uses Refs:
REF ?= $(PROJECT_DIR_pe_ww:http://lalashan.mcmaster.ca/theobio/projects:Refs)
REF ?= ../../projects/Refs
should do it. That is, if REFS is set, use it. Else if the default variable name is set, use that (*). Else assume we're in the old WW, and use the old-style path.
(*) Note, we won't have the convenient shorter default value, because that's set by the new WW at the time the prerequisite is assigned.
I don't think that double ?= works, because the first one sets the variable to '' if not to a real value.
It can be done using ifneq ($(origin VARIABLE), undefined), so I'll follow with a better recipe.
There was some difficulty with the long PROJECT_DIR variable name, taken care of in bug #3161233:
https://sourceforge.net/tracker/index.php?func=detail&aid=3161233&group_id=366300&atid=1527385
Another possible issue, though, is that when a pe-ww: project name is entered into the old WW as a prerequisite, it might create a project description for it that will confuse the new WW. I need to do some checking on that.
It's true, when you add it as a prerequisite in the old WW, it creates a project description for it, and because it doesn't put an "external" element in the description, it can misdirect the new WW into reading it as a local project with a long name. This leads to horrors such as "pe-ww:http://lalashan.mcmaster.ca/theobio/wonder_development/http://lalashan.mcmaster.ca/theobio/projects/Refs". I've put in a case in the new WW so that it recognizes the description of an external project, if the project name is a URI but there's no external element. I guess this should make it all work. I'll test a bit more.
Actually, "pe-ww:http://lalashan.mcmaster.ca/theobio/wonder_development/pe-ww:http://lalashan.mcmaster.ca/theobio/projects/Refs".
I've tested this pretty well now, and I think I'm satisfied. I used Refs as an example. I added a Refs_test page to the wonder_development wiki to test it. I put some lines in site/makefile-before:
ifeq ($(origin REF), undefined)
ifneq ($(origin PROJECT_DIR_projects_Refs), undefined)
export REF := $(PROJECT_DIR_projects_Refs)
else
export REF := ../../projects/Refs
endif
endif
This is what I recommend for upgrading, not any recipe using ?=. This supports all three cases that matter:
Given this, this is the upgrade path for a project that uses Refs:
The Refs code will work as designed at all stages of this process.
ps. No, that bad URI is actually "pe-ww:http://lalashan.mcmaster.ca/theobio/wonder_development:pe-ww:http://lalashan.mcmaster.ca/theobio/projects:Refs" - I don't know what my problem is today.
I should say explicitly - when doing those steps, you have to use the long form for the prerequisite, "pe-ww:http://lalashan.mcmaster.ca/projects:Refs", not the short form, "pe-theobio:projects:Refs", because the substitution needs to be done at the time it's assigned - the old WW won't substitute it correctly and after we upgrade we'll be stuck with a bad URI.