> On 29 Jul 2020, at 2:27 pm, Ken Cunningham <ken.cunningham.web...@gmail.com>
> wrote:
>
>> On Jul 28, 2020, at 9:22 PM, Ian Wadham <iandw...@gmail.com> wrote:
>
>> Also, Ken, I have worked out a way of maintaining a git repository of the
>> source code and edits that is external to MacPorts and entirely under my
>> control, so the need to avoid “install” is not so great. The compromise is
>> that, after a bunch of edits, I will be using a script I wrote called
>> “./ship” to copy the changed files down into MacPorts’
>> work/<source-dir-name> area, after editing and before (re)building and
>> testing.
>
>
> If you get that to a sharable state, pls post it up so I can have a look.
There’s nothing much to write home about.
Basically I have in my /kdedev/ports/kde/kpat portfile directory:
files/ portfile rebuild* repo/ work@
I just used mkdir to create repo/, then populated it using something like:
cp -R work/kpat-4.14.3/ repo
The ending slash on the source files of cp -R make it blatt all the files and
subdirs into repo/ without creating a new kpat-4.14.3/ subdir.
I then made repo/ into a git repository and added the script called “ship”.
At the moment, “ship” is just:
192-168-1-104:/kdedev/ports/kde/kpat>cat repo/ship
for f in $*
do
cp $f ../work/kpat-4.14.3/$f
echo "---" $f replaced in MacPorts
done
So I have to supply paths to recently edited files as parameters, but at least
they can be validated by using bash filename completions. Another possibility
is that I could use something like "git status --untracked-files=no —porcelain”
to get a parseable list of changes and so automate the copying of recently made
and not yet commited edits into MacPorts, within the script call “rebuild”.
The “rebuild script at present is:
192-168-1-104:/kdedev/ports/kde/kpat>cat rebuild
#
# Wind the MacPorts state-file back to just before "build" state.
sudo sed -e'/build/,$d' work/.macports.kpat.state >temp
sudo cp temp work/.macports.kpat.state
rm temp
# Re-build, using the most recently edited source code.
sudo port -v build
sudo port destroot
Note that “cp” only cares about “rwx” access rights, not ownership or group
membership. If the target file exists, it changes the contents of that file,
without changing its attributes. So the state-file and everything down in
MacPorts retain owner, group and access rights whenever my scripts change their
contents.
> I’ve been meaning to write something for a portfile to override the “extract”
> and “patch” portfile phases to just symlink the source directory into the
> work folder — come to think of it, that might be all I need to do — but
> haven’t got around to it.
>
> There are a few massive ports I work on:
>
> qt4-mac
> qt5.N for various older systems
> llvm-N
Errrmmm I would worry about making anything as big as those into single git
repositories.
In KDE, at least, every app or library is just one repository, but they are
grouped into categories (e.g. “kpat” is part of “games”). See
https://invent.kde.org/games/kpat on GitLab. I guess Qt can be broken up
similarly, from my experience of it. Divide and conquer… :-)
> that would benefit from this approach rather than what I do now.
With git, I am looking forward to using branches, where I can create and
evaluate alternate solutions to the bugs I am chasing. Also, until I merge
branches, I think I can easily get back to base with git checkout master, e.g.
to do "before and after" testing of fixes.
Cheers,
Ian W.
> Ken
