After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 689960 - Build improvements
Build improvements
Status: RESOLVED FIXED
Product: rygel
Classification: Applications
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: rygel-maint
rygel-maint
Depends on:
Blocks:
 
 
Reported: 2012-12-10 10:33 UTC by Murray Cumming
Modified: 2012-12-12 18:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-Improve-the-build.patch (57.26 KB, patch)
2012-12-10 10:33 UTC, Murray Cumming
none Details | Review
0001-Improve-the-build2.patch (58.11 KB, patch)
2012-12-12 10:28 UTC, Murray Cumming
committed Details | Review

Description Murray Cumming 2012-12-10 10:33:23 UTC
Created attachment 231133 [details] [review]
0001-Improve-the-build.patch

This doesn't solve any particular problem, but makes it easier to understand the build, by making it cleaner, and making it easier to see what dependencies are used by what executable/library.

It doesn't make the build files much shorter, if at all, but now that they are clearer and more consistent, maybe we can achieve that in subsequent steps.
Comment 1 Jens Georg 2012-12-10 15:04:03 UTC
Review of attachment 231133 [details] [review]:

::: configure.ac
@@ +73,3 @@
+
+# TODO: Maybe add gstreamer, gstpbu, and libsoup?
+RYGEL_COMMON_MODULES_VALAFLAGS="$RYGEL_BASE_MODULES_VALAFLAGS --pkg gupnp-av-1.0"

We can't add gstreamer here, that would make it impossible again to build rygel without gstreamer.

@@ -59,8 +58,28 @@
-PKG_CHECK_MODULES(LIBGSSDP, gssdp-1.0 >= $GSSDP_REQUIRED)
-PKG_CHECK_MODULES(LIBGUPNP, gupnp-1.0 >= $GUPNP_REQUIRED)
-PKG_CHECK_MODULES(LIBGUPNP_AV, gupnp-av-1.0 >= $GUPNP_AV_REQUIRED)
... 5 more ...
+PKG_CHECK_MODULES([LIBRYGEL_CORE_DEPS], [$RYGEL_BASE_MODULES uuid >= $UUID_REQUIRED gssdp-1.0 >= $GSSDP_REQUIRED gio-2.0 >= $GIO_REQUIRED])
+AC_SUBST([LIBRYGEL_CORE_DEPS_VALAFLAGS])
+RYGEL_BASE_MODULES='gupnp-1.0 >= $GUPNP_REQUIRED gee-0.8 >= $GEE_REQUIRED'
... 25 more ...

Doesn't the repeating checks for e.g. gio slow down the configure process?

@@ +291,3 @@
 
+
+RYGEL_ADD_PLUGIN([tracker],[Tracker],[yes])

Moving this (and similar) after the RYGEL_CHECK_VALA call breaks the forced vala mode on missing stamp files.
Comment 2 Jens Georg 2012-12-10 16:32:20 UTC
Also it looks like most of the G_LOG_DOMAIN things got lost.
Comment 3 Murray Cumming 2012-12-12 09:13:07 UTC
(In reply to comment #1)
> Doesn't the repeating checks for e.g. gio slow down the configure process?

Not significantly, and not that I've noticed. pkg-config checks are rather simple. Even if it was slower, it would be worth it for the simplicity and correctness.

> +RYGEL_ADD_PLUGIN([tracker],[Tracker],[yes])
> 
> Moving this (and similar) after the RYGEL_CHECK_VALA call breaks the forced
> vala mode on missing stamp files.

So can I just move the RYGEL_CHECK_VALA() call higher up, before any RYGEL_ADD_PLUGIN() calls?
Comment 4 Jens Georg 2012-12-12 09:44:38 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > Doesn't the repeating checks for e.g. gio slow down the configure process?
> 
> Not significantly, and not that I've noticed. pkg-config checks are rather
> simple. Even if it was slower, it would be worth it for the simplicity and
> correctness.

right, just wondering.

> > +RYGEL_ADD_PLUGIN([tracker],[Tracker],[yes])
> > 
> > Moving this (and similar) after the RYGEL_CHECK_VALA call breaks the forced
> > vala mode on missing stamp files.
> 
> So can I just move the RYGEL_CHECK_VALA() call higher up, before any
> RYGEL_ADD_PLUGIN() calls?

No, the other way round, for this to work RYGEL_CHECK_VALA must be called after all RYGEL_ADD_STAMP and RYGEL_ADD_PLUGIN calls.
Comment 5 Murray Cumming 2012-12-12 10:28:28 UTC
Created attachment 231335 [details] [review]
0001-Improve-the-build2.patch

> Also it looks like most of the G_LOG_DOMAIN things got lost.

No, they were moved to the specific *_CFLAGS. Actually, some were in the *_LDFLAGS, so I've moved them all to *_CFLAGS. I don't know which is best, but this is consistent.

This patch deals with all the other issues you mentioned too.