I apologise for repeating myself, but if one has local
changes, then one has a fork. What tools that are being
uesd to help track such changes is a separate question.
Given how loaded such discussions can easily become, I'll
point out that "git" provides a tool that helps manage such
things.
For building wxWidgets for use with my x64 fork, I started
by modifying the files in win/wxWidgets_additions/,
unzipping the relevant wxWidgets src files, and copying the
files over. One could then do a diff between these files
and 3.0.2 and compare that by hand to the diffs between
those files and 3.1 (the first release that supported
VS2015). It works. It is painful, but it works.
Eventually, I gave up and started working on a clone of the
official wxWidgets repo, keeping my changes first in a
stash, then I found that I could just keep my changes as an
"add"ed set of changes (without doing a commit). This got
more complicated when I tried switching to wxWidgets 3.0.3.
Finally, I gave up and just forked wxWidgets, checked in the
changes, and let to tools do their job. Much, MUCH easier.
Since the x64 fork links to the static, LTCG wxWidgets
libraries, they really should be built together. It seemed
reasonable to record the exact version of the wxWidgets
source (including local changes) used for the Audacity build
in the Audacity repo and so the x64 fork got a wxWidgets
submodule.
I'm not saying that any of the Audacity lib-src stuff should
be converted to submodules (or to use subtree or subrepo or
what-not), but I would say that if there are any local
changes at all, one should seriously consider having them
live in an SCM repo somwhere--even if that means every once
in a while copying the files that fork over the files in the
Audacity repo (i.e., hand merging). Rebasing local changes
on top of an external repo's changes is much easier and
error prone with "git rebase" than by typing "diff", making
changes in vi, and running "diff" again. Creating a pull
request from a fork to feed the changes upstream is a lot
easier when one has such a thing.
I suppose one could write a tool to automatically generate
the wxWidgets_additions folder from two branches... Given
how git is, well "git", I wouldn't be surprised if there is
already something like a "git make-cp-fork -o <output dir>
<from branch> <to branch>" tool.
Post by Paul LicameliWhat, if anything, is the discipline we should observe in updating lib-src
directories, if we don't use git submodules? This is pertinent to Henric's
proposals, which touch lib-src, and also the upgrade of expat, which I
still mean to do, but lately reverted because I thought I had been hasty
and did not follow good procedure.
For instance, in the case of expat, I see in git history that other things
were done to our copy of it, since last update. But I overwrote all
without considering whether I was supposed to replicate the changes that
were applied.
Should there be a procedure (as there is, for customized wxWidgets builds,
of putting .patch files into our git repository) for re-applying certain
patches to copied lib-src source trees? (And should we request such from
Henric?) Or simply a convention of putting a text file somewhere
describing the procedure for reapplying changes, if that is simple?
Was this procecure defined in writing already somewhere and am I just
inexcusably ignorant of it?
Nope, I don't think so. We are simply gradually getting better (=more
systematic) at tracking our own changes.
[2]https://github.com/audacity/audacity/blob/master/lib-src/
audacity-patches.txt
says there were no patches to expat. What changes did you find/spot?
If I do
gitk lib-src/expat
I see changes, not in source code, but chanign configurations, and I
don't understand them or know whether they are important to replicate.
There is also normalization of line endings by Benjamin, apparently
part of a big sweep, and probably unimportant.
If I do
gik lib-src
I see many, many things, and perhaps there are cautions we should
observe but did not.
But some lib-src directories are really totally ours, like mod*, and
some, like nyquist and perhaps portaudio, we have more influence on
upstream.
PRL
Â
PRL
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [3]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[5]https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [6]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
2. https://github.com/audacity/audacity/blob/master/lib-src/audacity-patches.txt
3. http://sdm.link/slashdot
5. https://lists.sourceforge.net/lists/listinfo/audacity-devel
6. http://sdm.link/slashdot
8. https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel