frogr @0.9 new Portfile

[juanrgar (Juan R. García Blanco)]

I've a question regarding this port. It tries to detect platform, OSX (quartz) or GNOME, and based on that defines a dependency on gstreamer or not. However, I guess that even if platform is quartz, gstreamer does not do any harm.

[cooljeanius (Eric Gallager)]

It tries to detect platform, OSX (quartz) or GNOME, and based on that defines a dependency on gstreamer or not.

Where does it try to do this?

[cooljeanius (Eric Gallager)]

Cc Me!

[juanrgar (Juan R. García Blanco)]

In configure.ac starting at line 54, it detects platform using GTK_CHECK_BACKEND, and based on the result it decides if gstreamer is needed or not. The same applies for a libsoup flag; if platform = GNOME, then it tries also to find libsoup-gnome.

I guess it is possible to detect in the Portfile whether gtk+ was built with quartz backend or with x11 backend. But my question is if it's worthwhile to do this and, based on this check, add a dependency on gstreamer or not. I guess it's much easier to ignore platform and always depend on gstreamer.

[dbevans (David B. Evans)]

Committed in r117259 with modifications:

• add run time dependency on epiphany since the app attempts to launch a GNOME-registered web browser as part of the initial account dialog.
• use autoreconf to re-configure using MacPorts intltool.m4.

[dbevans (David B. Evans)]

Concerning the x11/quartz configuration issues:

• The app built successfully for me with variants +quartz -x11. However, the +quartz version segfaults on startup.
• if you want to address the +quartz build, I suggest adding +quartz and +x11 variants (even if they are empty) to distinguish the two binary versions. See inkscape for an example. You can put the gstreamer dependency in the +x11 variant. The runtime dependencies should go in the +x11 variant too since none of them build with +quartz at this time. Of course, in this case, the help menu, web browser support and theming will probably not work correctly.
• if you want to preclude the +quartz build and make it obvious that it only will build as an X11 app then you can use the active_variants-1.1.tcl port group and use require_active_variants to error out if the +x11 build of gtk3 is not installed. In this case you don't need to add any variants.

Thanks for yet another GNOME submission.

[mario@…]

Hi, I'm the developer of frogr and just found out this bug report by chance, only to realize that I probably messed it up quite a lot with the last release, since I was not taking macports (or similar) into account. My most sincere apologies about that.

The only (and stupid) reason why the gstreamer is manually deselected when the platform is not GNOME is because I was using jhbuild to build frogr for Mac and, for some reason I had no time to investigate, I could not get GStreamer building and working properly under that environment, so I decided to disable it for now even if that would mean that frogr 0.9 for Mac would not have video uploads support. I did that because historically I did not worry much about the Mac version of frogr, as it was more an experiment to me than a real port. However, I'm using it more and more in the Mac since the latest versions, and perhaps others are doing it too, so guess it's time to take it more seriously :)

However, after finding this report I realized that such an idea was a terrible one, because I'm making macports people's lives harder "for free", since being in the OS X platform should not be a reason per-se to disable GStreamer and, therefore, video uploads in frogr for the mac.

So, this comment is just a "call for help" to ask for support to know which kind of changes I could do make macports people's lives easier when it comes to porting frogr *and* also whether there's any specific suggestion on how to improve certain parts. For instance, perhaps relying on GTK_CHECK_BACKEND to determine whether the platform is GNOME or MacOSX is not correct, and there's a better way to do that.

Any comments? Help is sincerely appreciated, since I'll be probably releasing a new version of frogr soon and I'd like to do it better next time, if possible.

Thanks!

[mario@…]

Just for your information, I've removed the logic from configure.ac that disable GStreamer support based on the platform and just added a new configuration flag --enable-video (enabled by default) that will require GStreamer if enabled.

That way, I hope it will be easier for other platforms to decide whether to go with or without that feature. See the commit in git.gnome.org: ​https://git.gnome.org/browse/frogr/commit/?id=4ab10d1943155d184041fc1a3f7f368f3bfeead4

Hope this helps, Mario

[mf2k (Frank Schima)]

Replying to mario@…:

Any comments?

Hi Mario. FYI commenting on a closed ticket is not an effective way to solicit comments because it will not be seen or read by many people. Please instead post to the ​Macports-Dev mailing list.

[juanrgar (Juan R. García Blanco)]

Sorry for the really late response. Thank you very much Mario :) We will check this as soon as possible; we are aware of the changes you made. Thank you.