Updating for a major GNU Make release

Periodically (about 2-4 years) GNU make comes out with a new major release. Here is the process to update remake.

For concreteness, below we'll use the process to update from remake 4.2 to remake 4.3.

Painful experience has shown that the right way to do this is to make two new branches: make-4-3 with the GNU make source, and another branch off of that remake-4-3.

Here is a picture of the current remake branching and tag structure in git:

gnu-make------+------+---------+-----------------+---------+---------+----------------------------+---->
             (3-80)  (3-81)   (3-82)            (4-0)     (4-1)      (4-2)                      (4-3)
                      |        |                           |         |                            |
                      |        |                           |         |                            |
                      |        + remake-3-82--->           |         + remake-4-2-->              + remake-4-3 ---->
                      |                                    |
                      |                                    |            (4-1+09) (4-1+091)
                      + remake-3-81-->                     +-remake-4-1-------------------->

There is no master branch.

With the 'diff"s from make-4-2 HEAD to remake-4-2 HEAD, "rebase" them onto the remake-4-3 branch.

In other words, do not build off of the existing remake-4-2 branch at HEAD.

In the last paragraph, I put "rebase" in quotes because I don't necessarily mean using git rebase. For such largish changes that might be too difficult.

I start out with addiing from the remake-4-2 branch a couple of .gitignore files so as to make sure the branch is there and has a couple of the new directories like debugger and unittest.

To simplify the process of patching from a new release of GNU Make to remake it can be done in stages.

In the beginning, it might be preferable to forget the debugger, and profiler and just focus on the stack-tracking changes which form the bulk of the changes and alas can't be isolated to a single module.

Or you might doit it the other way around and focus on the profiler first which is isolated, and then come back to the other stuff.

Also you probably want to leave out worrying about testing and the CI integration until later.

There will be a lot of stuff of the kind I think of as "administrative", code to build a tarball, pull in the language customization files (which is maintained independent of GNU Make) and so on.

More on to the big task of getting the tracing and calls to the debugger changed in GNU Make.

One big patch to look at to help guide you is the the overall diff's from GNU make 4.2 last to GNU make 4.3.

Some things to keep in mind.

First, remake doesn't support VMS, Atari (although, more on this below), riscos, OS2, DOS (with or without EMX) or native MS Windows,

The reason for this is that I don't have the means to test or support such things. Also historically the code to support these OS's in GNU Make has been horrendous and not very well isolated. It makes already harder-to-read code in jobs.c and makeint.h harder.

Second, although GNU Make code has always been a bit back-level in terms of using best practice C style and conventions, resist the temptation to try to fix this up. Eventually GNU Make does make forward progress, albeit at a snails pace, and invariablly the GNU make fixups will be different from those in you've decided on in remake. This adds additional work when the next release comes out.

Of course, if the back-leveness is in strictly remake code, such as in the debugger, then by all means go and fix up my crappy C code.

More with respect to rebasing...

Git is awesome and a really powerfull tool, but it helps if you keep in mind what's going on so you can use git to its full advantage.

The remake git repository does not aim to capture the full GNU Make history. If you are interested in GNU Make version-control history, use GNU make's version control for that.

Also I am not interested in tracking the full remake version control history across major GNU Make/remake releases. When you go from remake-4-2 to remake-4-3, the only thing that matters is the entire set of changes as one big patch from the most recent remake-4-2 to get to the most-recent remake-4-3. Of course, if you are interested in the ins-an-outs of how you got from make-4-2 to remake-4-2 you can use the git history within the remake-4-2 branch. Having that history also be in the remake-4-3 branch is not interesting.