On 10/18/2016 10:50 PM, Jason L Tibbitts III wrote:
"PM" == Panu Matilainen <pmatilai@xxxxxxxxxxxxxxx> writes:
PM> macroized into something like %cmake_setup, %cmake_build and
PM> %cmake_install? Okay, it requires somebody to actually do it and
PM> sanction but...
Well, I try but to be honest I thought cmake was fairly cleaned up. And
yes, I agree that to as much of a degree as possible, the macros for
various buildsystems should follow a basic
%configure/%make_build/%make_install pattern.
Oh, I wasn't picking on you, sorry if it came out like that. I don't
really know what all these build systems are, much less what their
"completeness" is :)
PM> Taking the idea a bit further, if everything were to follow such
PM> %foo_setup, %foo_build, %foo_install then at least in simple and/or
PM> well-behaved cases you could do the whole setup-build-install thing
PM> with one spec line wher just the type varies:
PM> %autobuild foo
Now look here. Usually I'm the one who proposes things like this, and
usually everyone tells me I'm insane and that the RPM people would never
go for it. And sometimes I do actually try implementing those things,
where I generally run into some minor thing that RPM proper would need
to add, but indeed the RPM folks aren't interested. Probably because
I'm not providing the needed patch to RPM, whose code simply hurts my
brain.
But if Panu's going to propose crazy things, too, then I'm going to
consider that ample justification and drag out some of those old ideas I
have stashed away.
I don't know what's so crazy about this.
But back to reality, I wish there were enough packages which actually
worked without needing to tweak something or pass extra flags or change
some permissions at the end of install or whatever to make this actually
something which would be generally useful. Because even if the super
simple thing works at some point in time, upstream is eventually going to
put out an update that requires you to tweak something, and then you'd
have to delete your pretty autobuild call and do back to the old school
way of doing things.
Yes, ability to selectively override and/or pick suitable pieces is
absolutely vital. If its just the magic oneline or everything manual
and nothing in between its just worthless.
Now if RPM let you have multiple %build or %install sections and just
concatenated them, then you could have %autobuild and then later an
%install section that removes that stuff you didn't want installed or
does that recursive permission change..... But it doesn't.
Multiple %build/%install might be one possible way but by no means the
only one.
For example rpm could automatically create default %build and %install
sections (like it does for %clean) from a template, and then if
something in the automation doesn't work you can override just the part
that doesn't work. And any such template would (have to) have pre, post
etc sections you can override/fill up.
Macros can go a long way but something like this would almost certainly
benefit from having some level of knowledge within rpm itself. In rather
broad strokes so to speak, invoking the automation could be something like:
ProjectType: cmake
That would (try to) populate default %build and %install from cmake
template, assuming such a thing exists, and in the simple case that'd be
all you need.
To tweak something in, say, %install, you'd then override that, invoke
the template macro manually and do your stuff around it as necessary, eg:
---
%install
%cmake_install_template
# upstream makefile leaves junk around
rm -rf %{buildroot}/...
---
Mind you, I haven't thought about the actual details here too much so
I'm sure there are pitfalls and everything, but something like this
should not be hard at all on rpm side.
- Panu -
- Panu -
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
