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 773437 - glib-compile-resources: Output depfile in same directory as target
glib-compile-resources: Output depfile in same directory as target
Status: RESOLVED NOTABUG
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2016-10-24 17:13 UTC by Patrick Griffis (tingping)
Modified: 2016-11-06 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glib-compile-resources: Output depfile in same directory as target (2.02 KB, patch)
2016-10-24 17:13 UTC, Patrick Griffis (tingping)
none Details | Review
glib-compile-resources: Output depfile in same directory as target (1.97 KB, patch)
2016-10-25 06:10 UTC, Patrick Griffis (tingping)
committed Details | Review

Description Patrick Griffis (tingping) 2016-10-24 17:13:03 UTC
Created attachment 338364 [details] [review]
glib-compile-resources: Output depfile in same directory as target

This is a common behavior expected for example by Meson and can be overridden with an absolute path.

This shouldn't be a breaking behavior since this feature didn't even work previous to commit 243c1b7e8 anyway.
Comment 1 Nirbheek Chauhan 2016-10-25 02:50:48 UTC
Wouldn't it make sense to preserve the directory components in the `dependency_file` argument while doing so? That gives a bit more control to the user in terms of where they want to place it while also not forcing them to use absolute paths (which break as soon as the build dir is moved).
Comment 2 Patrick Griffis (tingping) 2016-10-25 04:41:35 UTC
The reason I removed it is because that behavior is just sort of non-obvious where as an absolute path is very clear. If people actually read the docs I suppose that wouldn't be an issue though.
Comment 3 Nirbheek Chauhan 2016-10-25 04:54:56 UTC
Normally, programs have an option like -C or -d, etc which says "output everything in here". glib-compile-resources has never needed that because it only ever outputted one file.

Now that can output two, I think it makes sense to use the directory components of, say, a generated .c file (the primary output) as a way of implicitly saying "I want all output inside this directory". From that POV, I think relative paths passed to --dependency-file= should be relative to that directory.

Of course this might not be very clear as you say, so maybe we can do something else.

However, what is strange is silently discarding the dirname passed to the option, so I think we should not do that. We could error out if there are any directory components, but maybe doing the 'dumb' thing and just appending it to the output directory makes sense. ;)
Comment 4 Patrick Griffis (tingping) 2016-10-25 06:10:51 UTC
Created attachment 338381 [details] [review]
glib-compile-resources: Output depfile in same directory as target

Accept relative paths to targets output directory also.
Comment 5 Matthias Clasen 2016-11-02 18:37:03 UTC
Review of attachment 338381 [details] [review]:

I don't have a strong opinion on the details. This seems ok to me.
Comment 6 Patrick Griffis (tingping) 2016-11-02 21:45:00 UTC
Attachment 338381 [details] pushed as 9006940 - glib-compile-resources: Output depfile in same directory as target
Comment 7 Patrick Griffis (tingping) 2016-11-06 02:34:26 UTC
Since this merged I started using it in actual projects and my assertion about tools expecting this behavior turned out incorrect. Since nothing depends on this and nobody else had any strong opinions on it I felt it was best to avoid this complication making things actually harder in build systems and revert this. Sorry for the noise.