> On Nov 28, 2016, at 11:35 AM, Jeffrey Johnson <n3...@me.com> wrote:
>
>
> Yes, there were quite a few checkins since I created the forks. I updated all
> the
> repositories that did not need merging this weekend (but that wasn’t libhif).
>
rpm5/libhif:master is no sync’ed with “upstream”.
> Make yourself happy with libhif: all of my work was largely exploratory
> assessing what issues need to be solved. Feel free to clobber anything
> I checked in to start getting an easily updated master branch.
>
> I’ll create a “macports” branch for my MacPorts efforts going forward.
>
> Meanwhile its likely time to establish some structural cmake parameters for
> porting use like
> #ifdef RPM5
> and
> #ifdef MACOSX
> on rpm5:master.
>
Most of the reason that I attempted to avoid compilation on MACOSX is
to avoid restructuring the CMAKE build beyond setting a prefix to /opt/local.
Since you (and most devels) are likely working on some linux machine, then its
time to describe
the 3-5 cases that need to be handled with CMAKE include/library paths for a
dnf port.
Case #1: out-of-tree RPM5 is installed as “system” RPM
CFLAGS needs -I/usr/include/rpm (and remove “rpm/“ #include prefix
everywhere).
LDFLAGS needs … -lrpm-5.4 -lrpmdb-5.4 -lrpmio-5.4 -lrpmmisc-5.4
Case #2: out-of-tree parallel install next to “system” RPM
RPM5 has a build option
--enable-build-versionscript
to append VERSION to directories, executables, and libraries so that
multiple versions
of RPM can be installed in parallel. The option isn’t perfect: e.g.
expect “make install”
to clobber your existing rpm/rpmbuild before renaming with VERSION
appended,
most man pages and “rpm” locales will be clobbered, and modules (e.g.
python) haven’t
been attempted (but do have different names, and so won’t clobber
rpm.org “system” modules.
But with a little tinkeriing, one can pretty easily have multiple
VERSIONS of RPM5 installed in parallel,
and one can adjust RPM5 configuration macros to have multiple rpmdb’s
etc etc.
CFLAGS needs -I/usr/include/rpm-${VERSION}
LDFLAGS needs $VERSION in *.la files (for *.a static archives) and (if
you can’t live with linking only
the last installed *.so) will need additional naming to use the
full $VERSION in sonames which
current use a $MAJOR-$$MINOR for libraries
Case #3: in-tree RPM builds from CVS but is not installed and “system"
When RPM5 is built but not yet installed, include files and libtool
*.la files are in these directories
build/
lib/
rpmdb/
rpmio/
misc/
with the obvious changes to CFLAGS/LDFLAGS
Case #4: in-tree RPM builds from CVS with dnf integrated within the RPM CVS tree
The RPM5 CVS tree is mostly easily extensible to build additional
components
permitting development from a single tree. This provides a single build
of all
components that simplifies, say, testing and continuous integration.
Case #5: configurable RPM builds to enable/disable internal/external components
RPM5 has configure options to use either external (e.g. in /usr/lib) or
internal
(e.g. top level subdirectories) that could be extended to accommodate
dnf components.
Typical development on platforms that are already using RPM5 are case #1.
On platforms (like Fedora/Centos) that need rpm.org, case #2 using
—enable-build-versionscript
permits development. This is the end CMAKE problem that I need to solve on my
Fedora/Centos boxes
(but I may just go back to MACOSX development).
There is likely some means to achieve case #3 already implemented (but its not
exactly obvious)
in dnf, but RPM5 which uses libtool *.la files to implement embedding of
internal components in
librpmisc.* will likely need some largish changes.
Cases #4 and #5 are included mostly for informational purposes. I will attempt
implementations
@rpm5.org if/when the time comes.
The immediate need, however, is to start thinking/designing the changes to the
existing dnf CMAKE build(s) that
can accommodate the above 5 usage cases with minimal configuration
changes/efforts later.
hth
73 de Jeff
