[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-users
Subject:    Re: Fixing source-code bugs using MacPorts facilities.
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2020-07-27 5:30:51
Message-ID: 40617391-CA4C-45F9-9811-5A2196B2442B () gmail ! com
[Download RAW message or body]

Hi Ken and Ryan,

Thank you very much for your suggestions. I think I have got all of them working, \
including cycling repeatedly through editing the MacPorts version of source down in \
/opt/local/…, then cyling back through editing the state file, re-doing build and \
re-doing destroot.

There is just one fly in the ointment.

Ken's final step — sudo port -v -k install — does not work, or maybe works only \
on the first cycle. Looking in /Applications/MacPorts/KDE4/kpat.app/Contents/MacOS/, \
the new executable (file kpat) does not get staged in from the …/destroot/… \
directory structure.

This is the only runtime file that I am actually changing and KDE 4 does not care \
where its executable files come from.

So I would be happy to test by running the kpat executable that appears in the \
…/destroot/… structure, unless you guys have a better way.

Cheers,
Ian W.

> On 26 Jul 2020, at 5:37 pm, Ken Cunningham <ken.cunningham.webuse@gmail.com> wrote:
> 
> 
> On 2020-07-25, at 11:26 PM, Ryan Schmidt wrote:
> 
> > 
> > 
> > On Jul 26, 2020, at 01:15, Ian Wadham wrote:
> > 
> > > The above all worked very well, but only once… :-(
> > > 
> > > If I test the app I have installed and find there is still some problem, I need \
> > > to edit the source and go back to the build step. But "build" just says "--->  \
> > > Computing dependencies for kpat"  and exits, even if I use "sudo port -f \
> > > build". It does not see that the source has changed.
> > 
> > MacPorts keeps track of which phases have been completed. If you successfully \
> > build a port, for example, the build phase is marked completed and will not be \
> > attempted again until you clean and start over.  
> > To bypass that behavior, you can edit the state file (a file in the work \
> > directory whose name is .macports.${subport}.state) and remove lines from the end \
> > of it for completed phases that you want to retry. 
> 
> 
> Indeed as Ryan said.
> 
> I wanted to let you see the basics, without overwhelming you.
> 
> Once you can do that, as Ryan points out, you can delete the destroot and/or build \
> folders, edit  the state file, and have MacPorts redo the steps you want it to do. 
> You can also have macports just redo the destrooting without redoing the build, \
> editing the portfile, and passing "-o" to have it leave the build alone -- I do \
> this quite often for complex destrooting scenarios. 
> It is incredibly powerful, but it does miss one feature that I would really like -- \
> to be able to do this using a stable git repo on my system as the source folder, \
> rather than a transient one created for each build. 
> Ken
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]