> On Dec 5, 2016, at 9:09 AM, Alexander Kanavin
> <[email protected]> wrote:
>
> On 12/02/2016 07:01 PM, Jeffrey Johnson wrote:
>> What I need is to be able to see what cmake options you are using in order
>> to be able to build dnf pre-requisites without having to checkout (or
>> install)
>> OpenEmbedded,
>
> Sure, yes, but I guess you don't need them right now?
>
I’m ready when you are. Jump starting the porting effort by boot strapping
from common code is rate determining. There’s just too much code, and
too many layers, to do otherwise imho.
>> OK. This is either Case #2 (I am installing into /opt/local instead of
>> adding —enable-build-version-script
>> which is more complex) or Case #3 (building against a RPM CVS checkout) for
>> building.
>>
>> Which are you?
>
> Rpm 5 is built and then installed into a openembedded-specific sysroot
> directory (/path/to/sysroot/ which inside looks like a regular root directory
> with /etc /usr /var etc.), and then the rpm dependencies are configured to
> use that installation when building and running them. There is a
> --enable-build-versionscript in use. I'm using debian as a host machine, so
> there is no danger of clashing with host rpm.
>
Again, packaging != development, and adds a different delay and indeterminism
while satisfying packaging policies and build systems are negotiated.
I’d like to be able to build the entire stack needed without having to debug
packaging.
>> If you would like some help, I need to see what build options you are
>> attempting to use with RPM5.
>
> Thank you for the offer, I'll first try to amend existing rpm5 recipe with a
> bit of help from Mark; if that proves too hard, I'll try with devtool.
>
devtool, not configure, is the supported build procedure from CVS.
And truly devtool is far far more reproducible and easier to use than e-mail or
irc
to communicate what options are chosen and needed. There are too many
Have it your own way!
disablers to test every possible combination. I work with a maximally configured
RPM to ensure functional code. But that means that there are often minor flaws
building with some options disabled. I depend on users to feed me desired
configurations to detect and repair build failures.
RPM “cd tests && make clean test” (particularly when compiled with
-fsanitize:address)
is quite effective in finding issues in RPM.
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
