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 569015 - Generated win32 config.h file in git
Generated win32 config.h file in git
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal enhancement
: 1.1.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 704055 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-01-24 20:52 UTC by ogg.k.ogg.k
Modified: 2013-09-18 16:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description ogg.k.ogg.k 2009-01-24 20:52:38 UTC
Please describe the problem:
Some files are generated, yet in git.
It's a pain in the arse, as they needlessly either conflict, need a dummy
commit to move them out of the way, or prevent a clean pull.


Steps to reproduce:
1. clone (eg) gst-plugins-base
2. ./configure && make
3. git pull


Actual results:
error: Entry 'win32/common/config.h' not uptodate. Cannot merge.

The merge then fails.


Expected results:
the merge should succeed (bar any changes made to the tree leading to conflicts)


Does this happen every time?
Maybe, maybe not.


Other information:
.po files are also in git, and are also modified in the build process.
This means you end up with an unclean tree.
Please do not place generated files in the repository, it's always more pain that it alleviates.
Comment 1 ogg.k.ogg.k 2010-11-22 18:25:47 UTC
I've not had that happen in a while.
Since the file I mentioned was in a submodule, I can guess that I probably did not update that submodule properly, though I don't see why configure/make would have changed it to cause a future merge fail.
In any case, it seems fine now, so I'll call it a PEBKAC :)
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2010-11-27 18:44:09 UTC
This is still the case in ugly and bad and would be good to fix.
Comment 3 Sebastian Dröge (slomo) 2011-05-20 05:46:25 UTC
I think this is fixed now everywhere, right?
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2011-05-20 07:47:39 UTC
nope - bad still has it.
Comment 5 Nicolas Dufresne (ndufresne) 2013-07-12 14:24:49 UTC
*** Bug 704055 has been marked as a duplicate of this bug. ***
Comment 6 Nicolas Dufresne (ndufresne) 2013-07-12 14:25:55 UTC
(In reply to comment #3)
> I think this is fixed now everywhere, right?

Can you provide patch reference ?
Comment 7 Sebastian Dröge (slomo) 2013-08-23 10:42:34 UTC
<slomo> __tim: https://bugzilla.gnome.org/show_bug.cgi?id=569015  didn't you fix that recently?
<__tim> don't think it's fixed for -bad
<__tim> let me check
<slomo> how was it fixed elsewhere?
<__tim> basically, look at the end of e.g. configure.ac in -good
<slomo> __tim: manually creating that file and putting it as config.h-new, and only moving back in make dist?
<__tim> something like that
<__tim> there's a win32-update target iirc
Comment 8 Tim-Philipp Müller 2013-09-02 13:00:11 UTC
commit 994739332d229a96fdc6bee9932d72349c29c614
Author: Tim-Philipp Müller <tim@centricular.net>
Date:   Mon Sep 2 13:40:37 2013 +0100

    Change how win32/common/config.h is updated
    
    Generate win32/common/config.h-new directly from config.h.in,
    using shell variables in configure and some hard-coded information.
    Change top-level makefile so that 'make win32-update' copies the
    generated file to win32/common/config.h, which we keep in source
    control.  It's kept in source control so that the git tree is
    buildable from VS.
    
    This change is similar to the one recently applied to GStreamer
    and gst-plugins-good.  The previous config.h file in -bad was in
    pretty bad shape, so unlike core and base, I didn't attempt to
    leave it strictly the same, but fixed it as necessary.  Needs
    testing I cannot do myself.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=569015