#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)
Change History (10)
Changed 7 years ago by RJVB (René Bertin)
Attachment: | kchmviewer.diff added |
---|
comment:1 Changed 7 years ago by mojca (Mojca Miklavec)
Cc: | MarcusCalhoun-Lopez mojca added |
---|
comment:2 Changed 7 years ago by mojca (Mojca Miklavec)
Owner: | set to mojca |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:3 Changed 7 years ago by mojca (Mojca Miklavec)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Sorry for the screw-up. Will try again.
comment:4 Changed 7 years ago by mojca (Mojca Miklavec)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:5 Changed 7 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 7 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 7 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 7 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 7 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).
Marcus, would you be willing to address some of the issues that kchmviewer has with the qt5 PortGroup?