Page 1 of 1

Sharing personal legacy VP7 packages with VP8

Posted: 8 Feb 2018 20:06
by Harrison Pratt
A question for Thomas:

I have a code library (about 50 packages and 200 .pro files) that I use in VP7.5. I would like to use it in both VP7.5 & VP8 projects and be able to modify those from either VP IDE.

My puzzle is that the .pack and .ph files in this libray have #include statements that point to files in the VP7.5 pfc subdirectories (e.g., #include @"pfc\varM\varM.ph") which are not in equivalent VP8 pfc subdirectories, so project compilation in VP8 gives messages about deleting references to the VP7.5 files in my library packages.

Of course, it is logical to follow the compiler's suggestion ... if I weren't hoping to use the same library in existing VP7.5 projects.

(1) Must I have make a copy of my library for use in VP8?
-- or --
(2) Can I use the compiler_version constant with #if #then #else statments
in my library's .pack and .ph files to share the library code between VP version?

Then again, a "possible" option (2) of sharing the library may not be an optimal choice.

Any thoughts on this migration question?

Re: Sharing personal legacy VP7 packages with VP8

Posted: 9 Feb 2018 9:54
by Thomas Linder Puls
Let me start by explaining what we do here at PDC. All files are in a version control system. (We use Vault from Source Gear, but we consider shifting to Mercurial (which is much like Git)).

We have a set of company-wide shared tools. These are always in kept in sync with our latest development system, meaning that at the same time we make a change to PFC we also change those tools to fit with the PFC change, and we commit both changes to the version control system simultaneously (i.e. within a minute).

In this setup, different teams/projects/programs can either freeze the development tool and tools to a certain "history state" or they can choose to use the "current" version of things.

Such version control systems have the possibility to branch a code base into separate tracks that can be developed individually. We use such facilities when we have to make small conservative updates (typically bug fixing) to a certain program that has been released to a customer. Having separate tracks gives the program that you may have to make some changes in several branches, so we try to limit branching as much as possible.

We branch Visual Prolog when we make a public release, but otherwise we do not branch neither it or our company-wide tools. Instead (as mentioned above) teams/projects/programs stay can with a certain historical version. Should they find bugs in that historical version they will normally solve it by making shadow versions of relevant files in their own code base. The solution will also be applied in the development line of the tools/PFC so when the project is jumped to a new version that contains the solution the shadow files are removes again.

We have "developed" this strategy over long time, and it is complicated to explain and understand but it is actually quite "simple" in practice. This will not be the case if you use conditional compilation.

Anyways implicitly in this there are three relevant statements for you:
  • We do not attempt to directly share code between different versions. Or to maintain software so that it is compatible with several other versions of other software.
  • We never make development in old software (we may make bug fixes). New development is only made on top of the newest version in the "development branch".
  • Old programs lives with old versions of tools. New tool functionality is only obtained by upgrading to newer versions of the tools.
Should you really try to keep a single tools source base compatible with both Vip 7.5 and Vip 8 then I will suggest that instead of using conditional compilation make three directory structures:
  • One containing the .pro .cl and .i files.
  • One containg .ph and .pack files for Vip 7.5
  • One containing .ph and .pack files for Vip 8
In a Vip7.5 project you will have include path to the first two directories in a Vip 8 project you will have include path to #1 and #3.

The advantage of this is that the automatic update of .ph and .pack files will continue to work in these two individual sets of ph/pack files.

It will however be more difficult to create a new tools.

Re: Sharing personal legacy VP7 packages with VP8

Posted: 9 Feb 2018 10:06
by Thomas Linder Puls
By the way if you don't use a version control system then start immediately. Version control is a must for any programmer. It comes before the development system :-).

Many uses git (which seems to be "the new black"). It has extremely many features and possibilities, but that also makes it rather complex and gives it a rather steep learning curve. But there a cookbook tutorials on the WEB for nearly anything you need to do. (And in a small setup you don't need to bother yourself with the differences between branching and forking and how to rebase stuff).

Re: Sharing personal legacy VP7 packages with VP8

Posted: 9 Feb 2018 18:30
by Harrison Pratt
Thomas,

Thank you for the very clear road map for navigating version changes. I will avoid sharing new and old libraries since you have confirmed what I suspected: "here be dragons!" This is the time to eliminate old code that could be better implemented or already exists in the VP packages, too.

Yes, as you guessed, it also is time for me to "git" with a more formal means version control.