Re: [DynInst_API:] Improving the dyninst packaging

[William Cohen <wcohen@xxxxxxxxxx>]

On 04/25/2012 02:31 PM, Matthew LeGendre wrote:
> 
> Will,
> 
> We have several of these done and sitting on branches that are pending merges.  Once the appropriate branches are finally merged, but before the Dyninst 8.0 release, it would probably be worthwile to point you at a checkout so that you could test whether our changes meet your needs.
> 
> Details on the current progress is below.

Matt,

That is great. What git branch are the patches on?

Also how are things converted from the git repos to the official tarball?  It would be good to test the rpm build stuff on stuff that closely matches the future official tarballs.  Try to minimize the chance that something is found to be broken in a just released tarball.
> 
> On Wed, 25 Apr 2012, William Cohen wrote:
>> Hi All,
>>
>> I have been looking over dyinst and working on improving its packaging
>> so it is suitable for inclusion in Fedora.  There is currently a
>> bugzilla entry tracking the review of the package to see that it
>> follows the guidelines for packaging for Fedora:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=799089
>>
>> List of things working on to improve the packaging:
>>    -follow makefile target guidelines at:
>>        http://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
>>    -separate "make build" and "make install" process
>>    -support staged builds (install files in place other final location)
> 
> The above three items are done.
> 
>>    -use install command rather than cp for installation
>>    -use of .PHONY rules for install rules rather than dependencies
> 
> These two are not done, but would not be difficult to add.
> 
>>    -allow use %configure macro in spec file
> 
> I don't know my way around spec files, so someone else will have to comment on the state of this and what it would entail.  Perhaps Ray?

I have tried to use the %configure macro in the configure files because it pretty much sets everything that might be needed. However, when doing that with the current spec files causes things to fail during the build.

> 
>>    -use proper /usr/lib64 for machine that support both 32-bit and 64-bit
> 
> I tried to figure out the right way to do this, and despite spending significant time googling I was unable to figure it out.
  Does anyone know the proper way to test for and determine the lib install target? Preferably from autoconf?

There are some place where things seem to be hardcoded to /usr/lib. On multilib machines such as x86 and ppc this could be a problem. Don't want the code to try to link 64-bit code with 32-bit libraries.

> 
>>    -allow exclusion of boost files (use externally supplied ones)
> 
> This is done, though pending more testing.
> 
>>    -fix compiler warnings
> 
> This would be done as part of standard release procedures.
> 
> -Matt

-Will