Menu

#36 Upgrade safety question

closed
None
7
2012-08-30
2011-01-11
Lee Worden
No

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?

Discussion

  • Lee Worden

    Lee Worden - 2011-01-17

    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:

    • Make sure the prerequisites are recorded for all affected projects on the new wiki.
    • Fix up their makefiles so they accept the DEFAULT variable names for the prerequisites. We can do this so that the preferred variable name is also accepted.
    • Upgrade the software. This should not break any of those projects.
    • Then we can go and set the preferred variable names at leisure, and remove the makefile code for accepting the default names.

    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.

     
  • Lee Worden

    Lee Worden - 2011-01-18

    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.

     
  • Lee Worden

    Lee Worden - 2011-01-19

    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.

     
  • Lee Worden

    Lee Worden - 2011-01-24

    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.

     
  • Lee Worden

    Lee Worden - 2011-01-24

    Actually, "pe-ww:http://lalashan.mcmaster.ca/theobio/wonder_development/pe-ww:http://lalashan.mcmaster.ca/theobio/projects/Refs".

     
  • Lee Worden

    Lee Worden - 2011-01-24

    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:

    1. The calling project has Refs as a prerequisite and variable name is REF - the recommended new-WW configuration.
    2. The calling project has Refs as a prerequisite, but it's using the default variable name - this is what we'll have when we set the prerequisite in the old WW and then upgrade to the new WW.
    3. Neither environment variable is set - this is what we'll find in the old WW.

    Given this, this is the upgrade path for a project that uses Refs:

    1. In the old WW, set "pe-ww:http://lalashan.mcmaster.ca/projects:Refs" as a prerequisite.
    2. When that's done, we upgrade to the new WW.
    3. Then go back and set the variable name to REF and select "Do not copy".

    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.

     
  • Lee Worden

    Lee Worden - 2011-01-24

    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.

     

Anonymous
Anonymous

Add attachments
Cancel





Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.