Opened 4 years ago

Closed 3 years ago

#46978 closed submission (fixed)

port submission: extra-cmake-modules

Reported by: RJVB (René Bertin) Owned by: mkae (Marko Käning)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: kde-extra-cmake-modules

Description

This is a port for the Extra CMake Modules that are used by KF5 ("KDE 5") but are not limited to those frameworks.

Feedback on where exactly to install the files is welcome.

Attachments (3)

patch-doc-building.diff (1.0 KB) - added by RJVB (René Bertin) 4 years ago.
Portfile.2 (2.5 KB) - added by mkae (Marko Käning) 3 years ago.
my current status which doesnt work with +docs variant
Portfile (2.7 KB) - added by RJVB (René Bertin) 3 years ago.

Download all attachments as: .zip

Change History (46)

comment:1 Changed 4 years ago by pixilla (Bradley Giesbrecht)

In the event we wanted to add additional cmake modules from other sources would they be added to this port or would a new port make more sense?

Perhaps naming the port extra-cmake-modules-kde would prepare for a multi-source future.

comment:2 Changed 4 years ago by RJVB (René Bertin)

well, Debian and Ubuntu both call this extra-cmake-modules which seemed enough reason not to worry too much about future xtra CMake modules from different sources. But yes, I did consider to call this port kde-ECM, but didn't because of the aforementioned, and because port:ecm already exists and is something completely different.

kde-extra-cmake-modules would be more in line with current naming policies.

comment:3 Changed 4 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:4 Changed 4 years ago by mkae (Marko Käning)

Within KF5 this is called ECM only, without a "KDE-" in front of it. But since port:ecm already exists, it probably does make sense to introduce it as that. :)

Once your qt5 PortGroup is out this should adapt to that as well, I guess.

I figure we'd need a new Category 'kf5' even, as 'kde' and 'kde4' aren't really reflecting KF5...

Last edited 4 years ago by mkae (Marko Käning) (previous) (diff)

comment:5 Changed 4 years ago by RJVB (René Bertin)

KF5 may refer to it as ECM, but the package name in Debian/Ubuntu is extra-cmake-modules.

No need to adapt to a Qt portgroup, however I should have made this belong to the cmake portgroup because that's what seems to be most appropriate.

There's already a kde category; wouldn't that one remain appropriate to refer to "anything KDE, regardless the exact version" ?

Changed 4 years ago by RJVB (René Bertin)

Attachment: patch-doc-building.diff added

comment:6 in reply to:  5 ; Changed 4 years ago by RJVB (René Bertin)

Replying to rjvbertin@…:

No need to adapt to a Qt portgroup

Ahem, except when building the documentation ...

New draft attached. I've tried to do something "clever" because I find it overkill to record a hard dependency on Qt (and a Qt version) when that's only used to build documentation. So, when installing the +docs variant with Qt already installed the Portfile will simply use whatever version is there (starting with the newest), and won't record a dependency. Unless for some reason the user requests a specific Qt version, or when Qt isn't installed yet. In that latter case Qt4 is preferred, for now.

comment:7 in reply to:  5 Changed 4 years ago by mkae (Marko Käning)

Replying to rjvbertin@…:

KF5 may refer to it as ECM, but the package name in Debian/Ubuntu is extra-cmake-modules.

So it is in KDE's CI as well as kdesrc-build.

No need to adapt to a Qt portgroup, however I should have made this belong to the cmake portgroup because that's what seems to be most appropriate.

Yes, that should be assigned to the cmake PG, true.

There's already a kde category; wouldn't that one remain appropriate to refer to "anything KDE, regardless the exact version" ?

Well, 'kde' in any case, yes, but I figure we'd want also a KF5 portgroup then.

comment:8 Changed 4 years ago by mkae (Marko Käning)

I suggest to rename this to extra-cmake-modules to be consistent with KDE.

comment:9 Changed 4 years ago by RJVB (René Bertin)

I'd be in more in favour of keeping kde-extra-cmake-modules, in line with Bradley's suggestion. We don't have to do *everything* like on Linux, improving is allowed ;)

comment:10 in reply to:  9 Changed 4 years ago by mkae (Marko Käning)

Replying to rjvbertin@…:

I'd be in more in favour of keeping kde-extra-cmake-modules, in line with Bradley's suggestion.

Oh, I missed that one.

Fine with me! Let's do it like that then, pushing kde to the end. :)

comment:11 Changed 4 years ago by mkae (Marko Käning)

Seems like I can commit this as extra-kde-cmake-modules-kde once I have tested it here independently?

comment:12 Changed 4 years ago by mkae (Marko Käning)

BTW, is it intentional that the port itself doesn't have +qt4 as default_variant, but only the doc variant?

comment:13 Changed 4 years ago by mkae (Marko Käning)

Owner: changed from macports-tickets@… to mk@…

comment:14 Changed 4 years ago by mkae (Marko Käning)

Cc: mk@… removed

comment:15 in reply to:  12 Changed 4 years ago by RJVB (René Bertin)

Replying to mk@…:

BTW, is it intentional that the port itself doesn't have +qt4 as default_variant, but only the doc variant?

A dependency on Qt is introduced only when building the documentation, so there's no need for a default Qt variant without ... Installing the ECM without at least Qt installed may not make sense, but not registering an obligatory dependency when not required is better, IMHO.

comment:16 Changed 4 years ago by mkae (Marko Käning)

Yes, that indeed makes sense. Thanks for explaining it.

comment:17 in reply to:  6 Changed 4 years ago by mkae (Marko Käning)

Replying to rjvbertin@…:

Ahem, except when building the documentation ...

Why was this patch needed?

comment:18 Changed 4 years ago by mkae (Marko Käning)

Why do we need to use git?

Can we not fetch a release instead?

comment:19 Changed 4 years ago by RJVB (René Bertin)

Adapted and tested to work with cmake.out_of_source yes .

comment:20 Changed 4 years ago by mkae (Marko Käning)

OK, will deal with it later. Thanks for letting me know.

comment:21 Changed 3 years ago by mkae (Marko Käning)

I think I will commit this as extra-cmake-modules and not append -kde as a postfix, as this seems to be used only for KDE stuff anyways. OK?

comment:22 Changed 3 years ago by RJVB (René Bertin)

See the first 2 comments about why there's a kde bit in the name. Not because it's used only for/by KDE stuff, but because there might be other kinds of "extra cmake modules". A bit of a far shot, but not untrue.

comment:23 Changed 3 years ago by mkae (Marko Käning)

So, I've successfully built the raw port, but when I try the +docs variant, I run into this:

--->  Staging kde-extra-cmake-modules into destroot
Error: org.macports.destroot for port kde-extra-cmake-modules returned: can't read "qt_bins_dir": no such variable

Well, this machine doesn't have qt5-mac installed, just bare qt4-mac.

comment:24 Changed 3 years ago by mkae (Marko Käning)

Actually it would be more consistent to use the prefix kf5- as all other KF5 ports will have to do the same.

The default variant would change to +qt5 in that case, of course.

(This is inspired by Harald Fernengel's HOMEBREW tap.)

Last edited 3 years ago by mkae (Marko Käning) (previous) (diff)

comment:25 Changed 3 years ago by RJVB (René Bertin)

Your issue was caused by the fact that apparently setting a default_variant from the payload of another variant doesn't cause that default_variant's payload to be executed. In other words, you must have hit the default_variants +qt4 line, which I incorrectly thought would cause the Qt4 PortGroup to be included.

As to using a kf5 prefix ... I'm not sure. ECM is not bound to a specific KDE version, and it seems to me that it is actually used by at least 1 KDE4 project. I think that KF5 is still KDE, as KG6 and KH7 will be ;) In other words, I think kde- is perfect as a prefix; I didn't call it kde4- for a reason. What the default Qt variant will be is something that can be (re)evaluated by the time KF5 ports start appearing; that doesn't actually change a lot. ECM are just a bunch of CMake files; the dependency on Qt is only for building the documentation.

comment:26 Changed 3 years ago by RJVB (René Bertin)

I've upgraded the port to 5.12.0 and hopefully addressed your building issue.

comment:27 in reply to:  25 Changed 3 years ago by mkae (Marko Käning)

Replying to rjvbertin@…:

Your issue was caused by the fact that apparently setting a default_variant from the payload of another variant doesn't cause that default_variant's payload to be executed. In other words, you must have hit the default_variants +qt4 line, which I incorrectly thought would cause the Qt4 PortGroup to be included.

Seems so, yes.

As to using a kf5 prefix ... I'm not sure. ECM is not bound to a specific KDE version, and it seems to me that it is actually used by at least 1 KDE4 project.

Oh, if that's indeed so, then we should keep it as kde--prefixed.

I think that KF5 is still KDE, as KG6 and KH7 will be ;) In other words, I think kde- is perfect as a prefix;

Good.

the dependency on Qt is only for building the documentation.

I know.

comment:28 Changed 3 years ago by mkae (Marko Käning)

Did you test this if +qt5 is set to be the default variant:

$ sudo port install +qt4 +docs
--->  Computing dependencies for kde-extra-cmake-modules
Error: Unable to execute port: Can't install qt5-mac because conflicting ports are active: qt4-mac

?

This is the result I got with my Portfile.2 from below.

Last edited 3 years ago by mkae (Marko Käning) (previous) (diff)

Changed 3 years ago by mkae (Marko Käning)

Attachment: Portfile.2 added

my current status which doesnt work with +docs variant

comment:29 Changed 3 years ago by mkae (Marko Käning)

This must happen because the qt4-mac currently installed is still a non-concurrent one. :-)

Changed 3 years ago by RJVB (René Bertin)

Attachment: Portfile added

comment:30 Changed 3 years ago by RJVB (René Bertin)

No, even with the current coexistential problems with qt4-mac and qt5-mac, asking for +qt4 shouldn't lead to an attempt to install qt5-mac ...

I just didn't handle the various logical combinations correctly, very dumb error. I've modified that bit in my Portfile; see if it resolves your issue. I didn't touch the other parts yet. I had assumed the project had continued not making release versions available like when I first wrote the Portfile. I'll probably add a -devel subport that provides git snapshots.

comment:31 Changed 3 years ago by mkae (Marko Käning)

Thanks, René, I've committed this in r137900!

comment:32 Changed 3 years ago by mkae (Marko Käning)

Resolution: fixed
Status: newclosed

comment:33 Changed 3 years ago by mkae (Marko Käning)

Port: kde-extra-cmake-modules added; extra-cmake-modules removed

comment:34 Changed 3 years ago by mkae (Marko Käning)

Resolution: fixed
Status: closedreopened

I just tried this on a VM having the current (concurrent) qt5-mac installed:

$ sudo port -y install kde-extra-cmake-modules +docs
--->  Computing dependencies for kde-extra-cmake-modules
Error: Unable to execute port: Can't install qt4-mac because conflicting ports are active: qt5-mac

which shouldn't fail like this, as it should enter the first if() block of the docs variant!

The weird thing is that the file does exist:

$ ls /opt/local/libexec/qt5-mac/bin/qcollectiongenerator 
/opt/local/libexec/qt5-mac/bin/qcollectiongenerator

and yet the qt4 portgroup gets set for some obscure reason... Ideas?

comment:35 in reply to:  34 ; Changed 3 years ago by larryv (Lawrence Velázquez)

Look closer.

        if {[file exists ${prefix}/libexec/qt5/bin/qcollectiongenerator]} {

Does that file exist?

comment:36 Changed 3 years ago by larryv (Lawrence Velázquez)

Do the generated documentation files differ depending on whether kde-extra-cmake-modules +doc ends up using qt4-1.0 or qt5-1.0?

comment:37 Changed 3 years ago by mkae (Marko Käning)

I don't think so. This is more a question of which qt version would be used for building it.

comment:38 in reply to:  35 Changed 3 years ago by mkae (Marko Käning)

Replying to larryv@…:

Look closer.

Oh, no, you are right, THAT path does not exist, indeed. Thanks for pointing that out, Larry!

comment:39 Changed 3 years ago by mkae (Marko Käning)

@René: I guess the path issue above is stg which needs to get fixed in qt5-mac, right?

Or would you rather go for the approach of introducing a new port kde-qt5?

Last edited 3 years ago by mkae (Marko Käning) (previous) (diff)

comment:40 Changed 3 years ago by mkae (Marko Käning)

Tweaked in r138046 to match current qt5-mac.

comment:41 Changed 3 years ago by RJVB (René Bertin)

Honestly? I don't see why I would adapt my qt5 ports as long as no decision has been taken on where things get installed (qt5 AND qt4, and after my -methings- well-argued reply in the thread on qt5-mac improvements). I'd rather drop the adaptive logic completely, or hard-code a dependency on qtN-kde if I had confirmation that such port(s) would exist.

comment:42 Changed 3 years ago by mkae (Marko Käning)

Yeah, would be good to know in which direction we're moving with qt5*.

So, you think I shouldn't have committed r138046 then? (Ping)

Last edited 3 years ago by mkae (Marko Käning) (previous) (diff)

comment:43 Changed 3 years ago by mkae (Marko Käning)

Resolution: fixed
Status: reopenedclosed

This is committed as kde-extra-cmake-modules since a while.

Note: See TracTickets for help on using tickets.