Fixing source-code bugs using MacPorts facilities.

Ian Wadham at
Wed Jul 29 08:51:13 UTC 2020

> On 29 Jul 2020, at 2:27 pm, Ken Cunningham <ken.cunningham.webuse at> wrote:
>> On Jul 28, 2020, at 9:22 PM, Ian Wadham < at> 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 $*
    cp $f ../work/kpat-4.14.3/$f
    echo "---" $f replaced in MacPorts

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 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.

Ian W.

> Ken

More information about the macports-users mailing list