Bug 481314

Summary: qpidc source rpm build behaves differently if ../specs exists
Product: Red Hat Enterprise MRG Reporter: Jeff Needle <jneedle>
Component: qpid-cppAssignee: messaging-bugs <messaging-bugs>
Status: CLOSED WONTFIX QA Contact: Frantisek Reznicek <freznice>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.1CC: aconway, esammons, gsim
Target Milestone: 1.3   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-01 15:17:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.