port developer/maintainer conveniences (and GSoC)

[René J.V. Bertin]

Hi,

Recent comments (about a portfile editing function and how incremental builds "are not supported") on this ML have gotten me thinking again (oh boy :))

I agree that those 2 examples are not of interest for the average user, and I'm not even sure I'd use a dedicated Portfile editor myself. However I can think of a number of convenience features for people who spend significant amounts of time working on (rather than with) ports. I keep the build/work directories of large ports (like Qt, kdelibs, etc) around as long as I'm not done modifying code, be it for MacPorts-specific patches or changes that will be submitted upstream. They're too large to keep multiple build directories around, and to rebuild from scratch every time - and thus  I don't think I'm the only one following this approach.
So, some form of support for incremental building would be appreciated, for instance through reuse of the -f or --force flag in conjunction with configure, build and destroot to repeat those (and only those) steps even if they've already been done (`port destroot -f` would remove the destroot directory/ies in case a post-destroot block exists). I know all kinds of interactions can go wrong due to inappropriate pre- or post- blocks, but since you're probably editing the Portfile anyway that shouldn't be too much of an issue.
The patch phase is a different beast, which is why I left it out of the list; but IIRC some changes have already been made after I described the use of quilt on Debian and Ubuntu earlier, and I already submitted a patch that stores the names of patchfiles applied successfully in the .macports.*.state file. That alone makes it much easier to repeat the `port patch` phase until all patches apply cleanly when updating a port (you just have to reverse the last failed patch manually before correcting it and trying again).

What I'd really appreciate is an easier way to hook up this workflow with an IDE like Xcode, KDevelop or QtCreator. For that, I could think of new (hopefully :)) commands like
- `port printenv <port> [+variants]` to print out the environment that will be used for the configure and/or build phases
- `port configurecmd  <port> [+variants]` to print out the configure, cmake, qmake or whatever command that would be executed by the configure phase
- `port buildcmd  <port> [+variants]` idem for the build phase

Many IDEs have a possibility to set up projects that use custom build systems, and the port commands above should allow to do that.

Just my thoughts...

R.