merge configure/Makefile files

[daxim]

I have to jump through a number of hoops to get all targets built, see the calls to perl in the specfile below. Make it easier for packagers by combining the configure/Makefile, and taking care that the nqp binaries have different names.

%build
perl -i -lpe 's/^(NQP_EXE\s+=\s+nqp)/$1-pir/' tools/build/Makefile-Parrot.in
perl Configure.pl
perl -i -lpe 's/(..PBC_TO_EXE. ..NQP_PBC.)/$1\n\t\$(MV) nqp \$(NQP_EXE)/' Makefile
make
perl -i -lpe 's/(fill_template_file.*Makefile)/$1.jvm/' ConfigureJVM.pl
perl ConfigureJVM.pl
make -f Makefile.jvm

%check
make test
# make -f Makefile.jvm test
# fails t/jvm/06-sprintf.t, disable until next release

%install
make install DESTDIR=$RPM_BUILD_ROOT
make -f Makefile.jvm install
mkdir -p $RPM_BUILD_ROOT%{_bindir} $RPM_BUILD_ROOT%{_javadir}
mv install/eval-client.pl install/nqp-eval-client.pl
perl -i -lpe 's|$ENV{PWD}/install|%{_javadir}|g' install/nqp
mv install/nqp install/nqp-jvm
install -t $RPM_BUILD_ROOT%{_bindir} install/nqp-eval-client.pl
install -t $RPM_BUILD_ROOT%{_bindir} install/nqp-jvm
install -m 0644 -t $RPM_BUILD_ROOT%{_javadir} install/*.jar

%files
%defattr(-,root,root)
%doc CREDITS LICENSE
%{_bindir}/nqp
%{_libdir}/parrot/*/languages/nqp
%{_libdir}/parrot/*/library/*
%{_libdir}/parrot/*/dynext/*
%{_libdir}/parrot/*/include/*

%files devel
%defattr(-,root,root)
%{_includedir}/parrot/*/dynpmc/*

%files jvm
%defattr(-,root,root)
%{_javadir}/*.jar
%{_bindir}/nqp-eval-client.pl
%{_bindir}/nqp-jvm

[arnsholt]

I agree that we should merge the two configure files into one script, but I'm not sold on the need to generate two separate Makefiles. The default way to build stuff from source is configure, make, make install, and we shouldn't break that expectation lightly.

But if I'm understanding your use case correctly (I guess that the file is an RPM build script or some such?), you want a simple way to build NQP/Parrot and NQP/JVM and get them installed with different names. Is that right?

[daxim]

I'm not sold on the need to generate two separate Makefiles

With the current set-up, there are already two Makefiles, they are both named Makefile. The code above patches to disambiguate.

RPM build script or some such

specfile

you want a simple way to build NQP/Parrot and NQP/JVM

I can and did handle a lot of build weirdness with other software, but nqp's current build system exposes a limitation in how a specfile works, namely that the prep/configure, build, check/test, install steps are each called once and one cannot jump back. Thus, it's not possible to build like the nqp developers expect. However, it is easy to kick off the two chains in parallel stages (see patches above), but as the nqp build system reuses intermediate build artifact names, there's a lot of unnecessary recompilation taking place.

So I must qualify simple. It means that both targets must be possible from one build, e.g.:

perl Configure.pl --help
perl Configure.pl --prefix=/usr  # implies defaults: --with-parrot --with-jvm
make ; make test ; DESTDIR=… make install

get them installed with different names

Yes, installed files must not have the same fully qualified name.

[pmichaud]

Note that the intermediate build artifacts aren't currently interchangable across builds (even for the same backend); so it's not really "unnecessary recompilation". At least I think that's what you're referring to here.

Pm

[jnthn]

Aye, though I can easily see how somebody who doesn't understand how bootstrapping stuff works (which is probably the common case :-)) could watch the build output and conclude that there is "unnecessary recompilation" going on. It's the way it is for (good) reasons, though.

[jnthn]

More generally, we'll also need to work out what we want packaging of Rakudo and NQP to look like now we have different backends. One package for all the backends feels very wrong - you should be able to say "oh, just Rakudo on JVM" without it going and wanting to install the dependencies for 3 other backends you don't want. At the same time, we need some way to have multiple installed side by side without them all trying to stomp on one name. On the third hand, we'd probably like /usr/bin/perl6 to point to a default; most people only need one backend, but which they care for will vary.

[daxim]

update-alternatives and dpkg-divert and virtual packages and capabilities already handle that. Leave the packaging and creation of post-inst scripts to the packagers.

[diakopter]

Lars,
are you saying you would create separate packages for the different builds
against the different backends?

Thanks,
Matthew Wilson

On Thu, Oct 10, 2013 at 2:39 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯
notifications@github.comwrote:

update-alternatives and dpkg-divert and virtual packages and capabilities
already handle that. Leave the packaging and creation of post-inst scripts
to the packagers.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/110#issuecomment-26094181
.

Sent by the Internet

---

Login to LinkedIn to see my whole profile and Connect
http://linkedin.com/in/mattswilson

[daxim]

Yes, several binary packages. No, one build.

[diakopter]

@jnthn @pmichaud, it sounds like putting the different builds in different
build directories would work for this since the intermediate filenames
overlap so much... and then nqp-parrot, nqp-jvm, nqp-moar for the three
binary executables?

On Thu, Oct 10, 2013 at 3:33 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯
notifications@github.comwrote:

Yes, several binary packages. No, one build.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/110#issuecomment-26097347
.

Sent by the Internet

---

Login to LinkedIn to see my whole profile and Connect
http://linkedin.com/in/mattswilson

[pmichaud]

Yes, we can likely do separate per-vm build directories. The final destination directories for install(s) should be up to the packagers, of course.

Pm

[diakopter]

@daxim does that work for you? Is it okay to leave the 3 different (see the
moarboot branch of nqp for what will shortly be merged - the third backend
MoarVM) Configure.pl scripts separate, but create another that runs all
three for the .spec rpm build? Do you have another idea of how to do it?

Thanks

On Thu, Oct 10, 2013 at 5:05 PM, Patrick R. Michaud <
notifications@github.com> wrote:

Yes, we can likely do separate per-vm build directories. The final
destination directories for install(s) should be up to the packagers, of
course.

Pm

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/110#issuecomment-26102508
.

Sent by the Internet

---

Login to LinkedIn to see my whole profile and Connect
http://linkedin.com/in/mattswilson

[daxim]

If the build can run in stages, then it's okay.

[moritz]

Now there's only one Configure.pl left, which (when called with right options) can generate a Makefile that can build and install NQP for each backend, all in the same build directory. You can build them separately with make j-all, make p-all etc, or all in one with make all. I hope that makes packagers happy.