make kchmviewer build again, respecting "our" build settings

[RJVB (René Bertin)]

Cf. ​https://paste.macports.org/864f6be68dc9

kchmviewer failed to configure because it's set up for an out-of-source build and the mainstream qmake5 PG fails to check if the build directory exists before attempting to create a file in it.

It also fails to respect the default linker flags (configure.ldflags), which I've addressed together with another change to respect configure.optflags c.s.

[mojca (Mojca Miklavec)]

Marcus, would you be willing to address some of the issues that kchmviewer has with the qt5 PortGroup?

[mojca (Mojca Miklavec)]

In e356e9b44d2787a65bd37c7ad1276488be9b66ba/macports-ports:

kchmviewer: fix build, respect LDFLAGS

• Create configure.dir for an out-of-source build
• Respect LDFLAGS

See: #56128
Closes: #56107

[mojca (Mojca Miklavec)]

Sorry for the screw-up. Will try again.

[mojca (Mojca Miklavec)]

In 71d7554cc080456ca43961d7451b7c445e47e51e/macports-ports:

kchmviewer: fix build

pre-configure was too late, the PortGroup already needs the folder
in its own pre-configure phase

Closes: #56107

[RJVB (René Bertin)]

That's interesting, because I never ran into this issue with my own version of the qmake5 PG. Which is as I'd expect it: pre-configure blocks are concatenated as far as I know, so as long as the qmake5 PG is included before the Portfile declares a pre-configure block the one from the PG should be executed first.

[mojca (Mojca Miklavec)]

Yes, that's exactly what happened, totally expected/explicable, just not what the user might want. I first intended to fix the PG, but then I started thinking that we need a general concept of out-of-source builds (I just sent an email to the ML).

[RJVB (René Bertin)]

The user as port maintainer or as "joe user"?

The "issue" with pre or post blocks declared in a PG being executed before those of the Portfile is independent from out-of-tree builds, and IMHO inevitable.

In that context one might ask exactly when the configure.dir build.dir are created if they don't already exist. Apparently not before the pre-configure (pre-build) step is started, otherwise the issue at hand should never have existed.

[mojca (Mojca Miklavec)]

The user as port maintainer.

I assume that configure.dir and build.dir are never created. Maybe that should be a feature request.

[RJVB (René Bertin)]

To be precise, ${configure.dir} and ${build.dir}, and no, they are not created automatically.

The cmake PG creates the former (and thus normally the latter too) as the first thing in its pre-configure block. I missed that yesterday :-/

So yes, a feature (or pull!) request to ascertain that ${configure.dir} exists before starting the port (pre)configure code would be welcome IMHO, idem for ${build.dir} and the build code.

After all, this happens with ${destroot.dir}, no?

Of course that still leaves us with the current situation for a certain time, until the change makes it to a released "base" version and onto all user systems (I'd never support a change that forces users to upgrade MacPorts itself before being able to apply what could be a minor port upgrade).