Re: [OT] Best Practices: Populating RPM SPEC %defines in basic Ant build management
Preface: So, just to follow-up, and I'll let people pick this apart
as they see fit.
To re-iterate: We're using Ant to assemble/build RPMs, not JPackage
compliant RPMs, but just any RPMs, as part of our build management.
What we came up with is as follows.
build.xml target name=setup
- Call script to dynamically generate ivy.xml with artifacts, for each package
build.xml target name=build:
- Call script to tarball source, rpmbuild source RPM and then use
mock to build 1 or more targets required, for each package
build.xml target name=publish:
- Publish the artifacts, for each package
We're still playing with the script for building, but we're passing in
a 'Revision' which is appended to the end of the 'Release' on the RPM.
E.g., given a pacakge:
(name)-(version)-(Release).(arch)
The (Release) is ...
(baserel)(Revision).(disttag)
Again, looking for these types of standards/best practices for an
off-line/disconnected build system that won't be feeding to Upstream
or anything else.
On Wed, Oct 26, 2016 at 2:32 PM, Bryan Smith <b.j.smith(a)ieee.org> wrote:
PREFACE: My apologies as this may be off-topic. But I figured this
might be the best set of SMEs to ask this question, especially since
I'm drawing a blank from when I had to do this a few years ago.
Environment:
- Disconnected systems (no or very limited Internet access)
- Apache Ant build management
Best Practice Sought:
- Solution to populate %defines at the top of RPM SPEC files
Feel free to tell me to RTFM with a link or anything else. I just
haven't kept up with the latest set of 'Best Practices' and/or tools
to manage many of the common %defines at the top of RPM SPEC files in
an Ant build management solution.
I.e., I assume there is a way to manage this better than just some
scripts called as part of the buildfile that does direct file
manipulation (e.g., via sed) and/or populates via environmental
variables
Side Note: We were looking at introducing Maven-Nexus as well, but
we're sticking with just our Git repos and Ant to match our
traditional software development and its build process. This would be
for packaging things into RPM atop of all that.
Again, likely off-topic and/or remedial for this list, but I'd figure
I'd ask as I'm several years out-of-date.
-- bjs
--
Bryan J Smith - http://www.linkedin.com/in/bjsmith
E-mail: b.j.smith at ieee.org or me at bjsmith.me
--
--
Bryan J Smith - http://www.linkedin.com/in/bjsmith
E-mail: b.j.smith at ieee.org or me at bjsmith.me