Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#56107 closed defect (fixed)

make kchmviewer build again, respecting "our" build settings

Reported by: RJVB (René Bertin) Owned by: mojca (Mojca Miklavec)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: rjvbertin@…, MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), mojca (Mojca Miklavec)
Port: kchmviewer

Description

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.

Attachments (1)

kchmviewer.diff (1.8 KB) - added by RJVB (René Bertin) 3 years ago.

Download all attachments as: .zip

Change History (10)

Changed 3 years ago by RJVB (René Bertin)

Attachment: kchmviewer.diff added

comment:1 Changed 3 years ago by mojca (Mojca Miklavec)

Cc: MarcusCalhoun-Lopez mojca added

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

comment:2 Changed 3 years ago by mojca (Mojca Miklavec)

Owner: set to mojca
Resolution: fixed
Status: newclosed

In e356e9b44d2787a65bd37c7ad1276488be9b66ba/macports-ports:

kchmviewer: fix build, respect LDFLAGS

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

See: #56128
Closes: #56107

comment:3 Changed 3 years ago by mojca (Mojca Miklavec)

Resolution: fixed
Status: closedreopened

Sorry for the screw-up. Will try again.

comment:4 Changed 3 years ago by mojca (Mojca Miklavec)

Resolution: fixed
Status: reopenedclosed

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

comment:5 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by 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).

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by 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).

Note: See TracTickets for help on using tickets.