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 712630 - Revert "gsettings m4: check for .xml in src/builddir"
Revert "gsettings m4: check for .xml in src/builddir"
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gsettings
unspecified
Other All
: Normal normal
: ---
Assigned To: Allison Karlitskaya (desrt)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-11-18 19:34 UTC by Colin Walters
Modified: 2013-12-23 16:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Revert "gsettings m4: check for .xml in src/builddir" (1.42 KB, patch)
2013-11-18 19:34 UTC, Colin Walters 		accepted-commit_now Details | Review

Description Colin Walters 2013-11-18 19:34:17 UTC 
This reverts commit b3593693d918f0ae97094f6712d817180b8eea6a.

See: https://bugzilla.gnome.org/show_bug.cgi?id=712171#c3
See: https://bugzilla.gnome.org/show_bug.cgi?id=712171#c4

Tested using both srcdir == builddir and srcdir != builddir in hotssh.

Conflicts:
	m4macros/gsettings.m4
Comment 1 Colin Walters 2013-11-18 19:34:19 UTC 
Created attachment 260162 [details] [review]
Revert "gsettings m4: check for .xml in src/builddir"
Comment 2 Dan Winship 2013-11-19 13:01:18 UTC 
Comment on attachment 260162 [details] [review]
Revert "gsettings m4: check for .xml in src/builddir"

ship it. if it breaks something it should get a better commit message next time
Comment 3 Colin Walters 2013-11-19 13:16:38 UTC 
(In reply to comment #2)
> (From update of attachment 260162 [details] [review])
> ship it. if it breaks something it should get a better commit message next time

I'd like to at least try to get a comment from Ryan first; the status quo doesn't appear to break anything (which is a bit surprising actually, but apparently true).

Ryan - do you remember for what component you needed this fix?  If so can you retest with my patch on top?
Comment 4 Dan Winship 2013-11-19 14:55:49 UTC 
(In reply to comment #3)
> the status quo
> doesn't appear to break anything (which is a bit surprising actually, but
> apparently true).

As I understand it, it doesn't break anything because 'test -f "$<"' will always be true, and so d will always be set to ""
Comment 5 Allison Karlitskaya (desrt) 2013-12-22 18:03:06 UTC 
Any reason you guys didn't commit this yet?  I can't remember the purpose for the original patch, so I have no problem with this...