port submission: extra-cmake-modules

[RJVB (René Bertin)]

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.

[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.

[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.

[mkae (Marko Käning)]

Cc Me!

[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...

[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" ?

[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.

[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.

[mkae (Marko Käning)]

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

[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 ;)

[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. :)

[mkae (Marko Käning)]

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

[mkae (Marko Käning)]

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

[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.

[mkae (Marko Käning)]

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

[mkae (Marko Käning)]

Replying to rjvbertin@…:

Ahem, except when building the documentation ...

Why was this patch needed?

[mkae (Marko Käning)]

Why do we need to use git?

Can we not fetch a release instead?

[RJVB (René Bertin)]

Adapted and tested to work with cmake.out_of_source yes .

[mkae (Marko Käning)]

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

[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?

[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.

[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.

[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.)

[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.

[RJVB (René Bertin)]

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

[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.

[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

?

[mkae (Marko Käning)]

my current status which doesnt work with +docs variant

[mkae (Marko Käning)]

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

[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.

[mkae (Marko Käning)]

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

[mkae (Marko Käning)]

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?

[larryv (Lawrence Velázquez)]

Look closer.

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

Does that file exist?

[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?

[mkae (Marko Käning)]

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

[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!

[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?

[mkae (Marko Käning)]

Tweaked in r138046 to match current qt5-mac.

[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.

[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)

[mkae (Marko Käning)]

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