[opensuse-buildservice] autotools source service.
Hi All, I'm looking at how feasible it is to swap my old enlightenment "Nightly" build scripts from some pretty messy bash to obs source services. I could just use the git service but one of the things that my upstream are especially talented in is breaking builds from within tarballs generated by "make dist" so my question is has anyone looked at pulling the current git master, then running "./configure; make dist" and then building from the resulting tarball. The most annoying thing about this is to generate the tarball you need to run configure which involves having the right dependencies installed so in order to run it it really needs to be done from the build vm. My current thought is to just use the existing git source service then in the %setup section of the spec file, extract the git tarball run "autoconf; make dist" then extract the autotools tarball to an appropriate place then build from that in the build phase. The major downside to this is that it adds considerable changes to the spec file compared to something built from a standard release, can anyone think of a way to reduce these differences? I guess its generic enough that I could hide it away in a rpm macro. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Montag, 20. Juni 2016, 16:06:42 CEST wrote Simon Lees:
Hi All,
I'm looking at how feasible it is to swap my old enlightenment "Nightly" build scripts from some pretty messy bash to obs source services. I could just use the git service but one of the things that my upstream are especially talented in is breaking builds from within tarballs generated by "make dist" so my question is has anyone looked at pulling the current git master, then running "./configure; make dist" and then building from the resulting tarball.
The most annoying thing about this is to generate the tarball you need to run configure which involves having the right dependencies installed so in order to run it it really needs to be done from the build vm.
My current thought is to just use the existing git source service then in the %setup section of the spec file, extract the git tarball run "autoconf; make dist" then extract the autotools tarball to an appropriate place then build from that in the build phase. The major downside to this is that it adds considerable changes to the spec file compared to something built from a standard release, can anyone think of a way to reduce these differences? I guess its generic enough that I could hide it away in a rpm macro.
Hm, one option would be to have a source service to run the autotools before creating the tar ball. We recommend these to create the tar ball anyway during the build phase, so you could inject your own source service before creating the tar ball. All what you need is to create such a script and build a rpm from it, so it can be used. Check this blog entry: http://openbuildservice.org/2016/04/08/new_git_in_27/ In your case a service file would look like this: <services> <service name="obs_scm"> <param name="url">git://github.com/mavlink/qgroundcontrol.git</param> <param name="scm">git</param> </service> <service mode="buildtime" name="simons_auto_stuff_executer" /> <service mode="buildtime" name="tar" /> <service mode="buildtime" name="recompress"> <param name="file">*.tar</param> <param name="compression">xz</param> </service> <service mode="buildtime" name="set_version" /> </services> Please note the "simons_auto_stuff_executer" service. This would can be a special service written by you which is doing $the_right_thing for you. Would be nice of course when you write it in a generic way, so it can be used also by others;) Does this lead into the direction you are thinking? Tell if you need help with such a service ... -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 06/20/2016 04:21 PM, Adrian Schröter wrote:
On Montag, 20. Juni 2016, 16:06:42 CEST wrote Simon Lees:
Hi All,
I'm looking at how feasible it is to swap my old enlightenment "Nightly" build scripts from some pretty messy bash to obs source services. I could just use the git service but one of the things that my upstream are especially talented in is breaking builds from within tarballs generated by "make dist" so my question is has anyone looked at pulling the current git master, then running "./configure; make dist" and then building from the resulting tarball.
The most annoying thing about this is to generate the tarball you need to run configure which involves having the right dependencies installed so in order to run it it really needs to be done from the build vm.
My current thought is to just use the existing git source service then in the %setup section of the spec file, extract the git tarball run "autoconf; make dist" then extract the autotools tarball to an appropriate place then build from that in the build phase. The major downside to this is that it adds considerable changes to the spec file compared to something built from a standard release, can anyone think of a way to reduce these differences? I guess its generic enough that I could hide it away in a rpm macro.
Hm, one option would be to have a source service to run the autotools before creating the tar ball.
We recommend these to create the tar ball anyway during the build phase, so you could inject your own source service before creating the tar ball. All what you need is to create such a script and build a rpm from it, so it can be used.
Check this blog entry:
http://openbuildservice.org/2016/04/08/new_git_in_27/
In your case a service file would look like this:
<services> <service name="obs_scm"> <param name="url">git://github.com/mavlink/qgroundcontrol.git</param> <param name="scm">git</param> </service> <service mode="buildtime" name="simons_auto_stuff_executer" /> <service mode="buildtime" name="tar" /> <service mode="buildtime" name="recompress"> <param name="file">*.tar</param> <param name="compression">xz</param> </service> <service mode="buildtime" name="set_version" /> </services>
Please note the "simons_auto_stuff_executer" service. This would can be a special service written by you which is doing $the_right_thing for you. Would be nice of course when you write it in a generic way, so it can be used also by others;)
Does this lead into the direction you are thinking?
Tell if you need help with such a service ...
The main problem with such a service is due to the fact it needs to run ./configure (autoconf) before being able to generate the tarball with "make dist" you need to have all the dependencies installed on the machine your using to run the service. In the case where you have a repo with libx and liby and the git version of liby depends on the git version of libx this gets quite annoying especially when libx is a core library for your Desktop Environment that you don't necessarily want to be using on your machine. In the past I got around that by doing the build in a virtual machine but it would be nice if I could come up with a way of doing this on any machine with the help of obs. Of the long list of things I dislike about auto tools this issue is probably right at the top. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Montag, 20. Juni 2016, 16:30:01 CEST wrote Simon Lees:
On 06/20/2016 04:21 PM, Adrian Schröter wrote:
On Montag, 20. Juni 2016, 16:06:42 CEST wrote Simon Lees:
Hi All,
I'm looking at how feasible it is to swap my old enlightenment "Nightly" build scripts from some pretty messy bash to obs source services. I could just use the git service but one of the things that my upstream are especially talented in is breaking builds from within tarballs generated by "make dist" so my question is has anyone looked at pulling the current git master, then running "./configure; make dist" and then building from the resulting tarball.
The most annoying thing about this is to generate the tarball you need to run configure which involves having the right dependencies installed so in order to run it it really needs to be done from the build vm.
My current thought is to just use the existing git source service then in the %setup section of the spec file, extract the git tarball run "autoconf; make dist" then extract the autotools tarball to an appropriate place then build from that in the build phase. The major downside to this is that it adds considerable changes to the spec file compared to something built from a standard release, can anyone think of a way to reduce these differences? I guess its generic enough that I could hide it away in a rpm macro.
Hm, one option would be to have a source service to run the autotools before creating the tar ball.
We recommend these to create the tar ball anyway during the build phase, so you could inject your own source service before creating the tar ball. All what you need is to create such a script and build a rpm from it, so it can be used.
Check this blog entry:
http://openbuildservice.org/2016/04/08/new_git_in_27/
In your case a service file would look like this:
<services> <service name="obs_scm"> <param name="url">git://github.com/mavlink/qgroundcontrol.git</param> <param name="scm">git</param> </service> <service mode="buildtime" name="simons_auto_stuff_executer" /> <service mode="buildtime" name="tar" /> <service mode="buildtime" name="recompress"> <param name="file">*.tar</param> <param name="compression">xz</param> </service> <service mode="buildtime" name="set_version" /> </services>
Please note the "simons_auto_stuff_executer" service. This would can be a special service written by you which is doing $the_right_thing for you. Would be nice of course when you write it in a generic way, so it can be used also by others;)
Does this lead into the direction you are thinking?
Tell if you need help with such a service ...
The main problem with such a service is due to the fact it needs to run ./configure (autoconf) before being able to generate the tarball with "make dist" you need to have all the dependencies installed on the machine your using to run the service.
In the case where you have a repo with libx and liby and the git version of liby depends on the git version of libx this gets quite annoying especially when libx is a core library for your Desktop Environment that you don't necessarily want to be using on your machine. In the past I got around that by doing the build in a virtual machine but it would be nice if I could come up with a way of doing this on any machine with the help of obs.
Well, it would run right before calling rpmbuild in the same environment. So, you would have all dependencies from the spec file. Or you can add dependencies to your service package, so they will get pulled in as well. It is also possible to have two seperate environemts for creating the tar ball and doing the build. But it would make it way more complex and slower. So I would suggest to try to it in the same env.
Of the long list of things I dislike about auto tools this issue is probably right at the top.
Yes, you are not the first one complaining about them ;) -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mon, Jun 20, Simon Lees wrote:
Of the long list of things I dislike about auto tools this issue is probably right at the top.
Just dont ship any autogenerated files. The approach to force every pkg to include a configure script was probably valid 40 years ago. Its obsolete since many many years. I'm sure Enlightment (like any other software project) has a list of buildtime dependencies. Having autoconf/automake in that list is the right thing and comes with no price. Update the docs to refer to autogen.sh rather than configure. Olaf -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Monday 2016-06-20 09:16, Olaf Hering wrote:
On Mon, Jun 20, Simon Lees wrote:
Of the long list of things I dislike about auto tools this issue is probably right at the top.
Just dont ship any autogenerated files. The approach to force every pkg to include a configure script was probably valid 40 years ago. Its obsolete since many many years.
It depends on the program. Of course, everybody should™ use PKG_CHECK_MODULES([gtk-2.0]) PKG_CHECK_MODULES([Qt5Gui]), but if a hypothetical two-frontend-capable program's configure.ac uses ancient m4 macros like AM_WHATEVER_GTK and AX_QT_BLAH, you need both gtk/qt installed just to get the m4 files for autoreconf - instead of just pkgconfig. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Monday 2016-06-20 08:36, Simon Lees wrote:
I'm looking at how feasible it is to swap my old enlightenment "Nightly" build scripts from some pretty messy bash to obs source services. I could just use the git service but one of the things that my upstream are especially talented in is breaking builds from within tarballs generated by "make dist" so my question is has anyone looked at pulling the current git master, then running "./configure; make dist" and then building from the resulting tarball.
Your end goal is a binary build, so why bother with creating a `make dist`-made tarball? Download from git, run autoreconf, configure, make all.
The most annoying thing about this is to generate the tarball you need to run configure which involves having the right dependencies installed so in order to run it it really needs to be done from the build vm.
To run configure, you only need the dependencies it considers mandatory, which is often a set _smaller_ than the set of dependencies required to get everything expanded right by m4. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 06/20/2016 04:59 PM, Jan Engelhardt wrote:
On Monday 2016-06-20 08:36, Simon Lees wrote:
I'm looking at how feasible it is to swap my old enlightenment "Nightly" build scripts from some pretty messy bash to obs source services. I could just use the git service but one of the things that my upstream are especially talented in is breaking builds from within tarballs generated by "make dist" so my question is has anyone looked at pulling the current git master, then running "./configure; make dist" and then building from the resulting tarball.
Your end goal is a binary build, so why bother with creating a `make dist`-made tarball? Download from git, run autoreconf, configure, make all.
The binary build is one of my two end goals the other is testing the "make dist" tarball because thats how my upstream ships there releases and they manage to break it reasonably often. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (4)
-
Adrian Schröter
-
Jan Engelhardt
-
Olaf Hering
-
Simon Lees