On Monday, October 17, 2016 8:55:27 PM CEST Igor Gnatenko wrote: > On Mon, Oct 17, 2016 at 7:13 PM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > On 10/17/2016 04:37 PM, Igor Gnatenko wrote: > >> > >> Hi, > >> > >> during last FPC meeting we agreed[0] > > > > Well, it was not agreed. Actually, I quit the meeting in protest against > > your plan and your lack of understanding. > > > >> that we need some standardization > >> of macro related to builds where builddir != srcdir (and with > >> possibility to make it builddir = srcdir). > > > > For decades, this is has been called VPATH-builds in make terms. > > > >> I was working to make guidelines for ninja and meson. For ninja it > >> doesn't matter from where you build (it's like make), but meson itself > >> accepts ONLY out-of-tree builds. Would be nice to get system-wide > >> (rpm-wide?) macro which stands for: > >> 1) source directory where CMakeLists.txt/meson.build/configure are > >> 2) build directory (I think _target_platform is a good candidate) > >> > >> to make out-of-tree conversion to in-tree, you do the RPM variable > >> override. > > > > I don't see any need to do so nor has there been any demand for such beasts > > ever since rpm exists. > > > > $(PWD), pushd/popd, sub-shelling are common means to avoid these. > > > >> For example, in openSUSE it's defined in cmake[1] as __builddir and > >> __srcdir. > > > > Yes, SUSE always has a long history in cluttering their specs with useless > > macros and questionable features. > > > >> Ideas, suggestions are appreciated! > > > > IMO, just drop this idea. It's featuritis. > > > > Pavel > > Problem is that with meson everyone will need to put this boilerplate > stuff in *each* spec. Is this strictly %meson related? Could the generalizing be done in `redhat-rpm-macros` within %meson_ namespace so we can avoid touching all packages? Though I'm not aware of the actual PoC, neither what boilerplate typing needs to be done for every %meson package, probably worth sharing ... Pavel _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
