Hi Jeff, Hi all, I'm resuming this (old) topic in case somebody is interested, I created a very small and simple Python utility
https://github.com/f18m/rpm-make-rules-dependency-lister that does what I was describing in this topic: it allows to connect in a slightly smarter way GNU make and rpmbuild, and to avoid unnecessary RPM re-packaging operations HTH, Francesco 2018-03-27 3:31 GMT+02:00 Jeff Johnson <n3...@me.com>: > > > On Mar 26, 2018, at 6:15 PM, Francesco <francesco.monto...@gmail.com> > wrote: > > Hi Jeff, > thanks for your reply. > > > > 2018-03-26 19:04 GMT+02:00 Jeff Johnson <n3...@me.com>: > >> >> There isn't an explicit tool to convert rpmbuild dependencies to Makefile >> dependencies afaik. >> >> OTOH, it's not impossibly hard to script a couple of missing pieces that >> are needed: >> >> 1) Automate by rule generating a *.src.rpm from a (possibly modified) >> *.spec. >> >> 2) Automate by rule installing a *.src.rpm into a local build directory. >> This requires configuring some rpm macros to map rpmbuild inputs/outputs >> into a single directory. >> >> 3) Automate by rule rebuilding of binary *.rpm from a newer *.spec in the >> local build directory >> >> You can find some useful rules using wild cards and % template rules in >> rpm5 sources: see the >> tests/Makefile.am file for the pattern rules. >> > > Honestly I'm not sure to understand what you mean... when you say > "Automate by rule" you mean writing a GNU make rule, right? > > > Yes. > > Then it's clear to me step 1 and 2 but is not clear why should I get a > newer .spec file in the local build directory only if some of my sources > have changed: if step 1 and 2 are always executed by GNU make (which btw > would be against my goal of running unneeded packaging operations) then I > guess that the mtime of the .spec file in the local build directory will > always change from run to run... what am I missing? > > > Sorry to be obscure. The pattern rules I wrote had 2 *.spec files: the top > level *.spec determined when a *.src.rpm should be made, which triggered an > install not a subdirectories, with a 2nd *.spec (copy) that triggers a > rpmbuild by rule. > > Does that make sense? worksforme, for the purposes I needed, QA testing of > a just built version of rpm within the buil tree ... > > Also I'm particularly interested in binary-only RPMs (I need such a tool > for a commercial software)... to give you an idea, most of my RPM spec > install sections look like: > > %install > make -C ../mysources mytarget_install DESTDIR=%{buildroot} > > > That's pretty generic, yes. Meanwhile the real problem is that rpmbuild > within Makefiles is kinda awkward. > > > >> Alternatively, one could attempt generating a Makefile include rule. >> >> Extract (and filter) rpmbuild dependencies from a spec (or *.src.rpm) >> file. RPM can query a spec file (or *.src.rpm), convert those (filtered) >> dependencies to package names, and convert the package names to file names >> that have a time stamp that can be included into a Makefile. >> >> > Sorry, I'm not sure I get this either... I know RPM allows you to query > dependencies but you can only query the package names listed under > "Requires:" isn't it? > > > Basically yes. But to automate within a Makefile (like dependencies on > *.h)' the build requirements need to be mapped onto a file name that has a > time stamp. > > > Btw I have sketched out a possible "solution" for my problem: first time > "make" is run, I call rpmbuild and build my binary RPM. > Then (automatically via GNU make rules) I unzip that RPM into some > temporary folder, I see what's inside and go search for MD5-sum matching > files in the source build folder. Every time I find inside the source build > folder a file that is inside the RPM, I write that into a .d file (same > name of the RPM spec). > The GNU makefile has an "include $(MY_SPEC_FILE_LIST:.spec=.d)" statement, > so that it's aware of the auto-discovered dependencies of the spec file. > Next time I run "make", it will be able to understand if the RPM is up to > date or needs to be regenerated because some of the file it packages has > been updated (perhaps as a result of the build process). > > > Post a sample Makefile please. Lots of people have tried to use rpmbuild > in Makefiles, and most of the solutions I have seen are rather awkward. > > Of course this process is not 100% accurate: in the %install section some > temporary file may be generated and copied inside the RPM build root. Or > files (e.g. config files) could be renamed when they get copied inside the > build root. And maybe there are other cases as well. > > > My pattern rules have some *ahem* issues as well, but are good enough for > "make test" automation. > > (aside) > The issues happen while developing: the pattern rules implicitly fire a > (perhaps buggy) rpm. Good enough, but sometimes a pita. > > However that approach might cover a wide range of use cases... what do you > think? > > It would be nice to have some mechanism like that inside rpmbuild so that > I can do > rpmbuild -MD myspec.spec --output=myspec.d > and it generates such dependency file for GNU make... > > > There aren't any clean or obvious solutions by rpmbuild design. Oh well ... > > hth > > 73 de Jeff > > Thanks! > > Francesco > > > >
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
