Bug 481314 - qpidc source rpm build behaves differently if ../specs exists
Summary: qpidc source rpm build behaves differently if ../specs exists
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 1.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: 1.3
: ---
Assignee: messaging-bugs
QA Contact: Frantisek Reznicek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-23 15:20 UTC by Jeff Needle
Modified: 2015-11-16 00:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-01 15:17:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jeff Needle 2009-01-23 15:20:53 UTC
This is a spinoff of bug 481307 since there are really two different issues that need to be addressed independently.

Justin's additions to 481307 explain the issue in building qpidc srpm.  See 481307 for relevant log snippets.


"Additional info:
2. The test that qpid/cpp is using to determine whether to generate code is
possibly wrong.  It appears that if a spec file is present at all at
../specs/qpid.0-10....xml, it generates code.  This is not favorable when we
build from our dist tarball.

It would be better if the qpid/cpp makefiles instead checked to see if the code
was already generated, as it is in dist tarball's case."

Comment 1 Alan Conway 2009-02-16 14:12:40 UTC
I think this is just a matter of adding the rgen.timestamp and mgen.timestamp files to EXTRA_DIST, since these are the files that make is using to determine if generated code is current.

Comment 3 Alan Conway 2010-01-11 19:41:47 UTC
comment 1 is not correct. From a developers point of view you want the code re-generated if the xml spec file is newer than any of the generated files. In an installation or in the distro I don't think we can't guarantee what the relative times of those files will be.

Comment 4 Gordon Sim 2010-07-01 15:17:08 UTC
The brew build now always regenerates sources from specs so the original issue is no longer a problem. While more control over regeneration may be worth looking at in the future it is not a pressing issue.


Note You need to log in before you can comment on or make changes to this bug.