<div dir="ltr"><div><div>I just need an option to skip the packaging steps, so I added a -n option for that purpose to tar_em_up.sh now, see attached diff. It would be nice if you can commit this as well.<br><br></div>I already have some extra infrastructure to create the necessary source tarballs and run debuild to create the source and binary deb packages, this all works in an automatic fashion. Will post these later. The package builds fine now, I just need to test with pbuilder and then on Launchpad that it works in a pristine and chrooted build environment. Stay tuned.<br><br></div>Albert<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 12, 2014 at 2:40 PM, Ivica Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">The final deb building is embedded in the line where we pass it install prefix which invokes one of the makefiles inside the packages sub-folder. This means that you will probably have to export a variable just like I do for the incremental building of the gem library ( building of gem in incremental builds is ignored because it takes so long). So, what I do is in the tar_em_up script I export a variable when incremental option is selected and then check for that variable inside of the Makefile located in the externals folder. We could amend the Makefile that does the building of the Deb package which is located in packages subfolder (either packages or packages/linux_make, can't remember which), and then check for the newly exported variable when using the proposed - L flag for launchpad and skip building of the Deb as well as moving of the file into a different folder. Please note that moving of the final deb file is IIRC performed at the end of tar_em_up script. HTH</p>
<div class="gmail_quote"><div><div class="h5">On Nov 12, 2014 8:25 AM, "Albert Graef" <<a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 12, 2014 at 4:04 AM, Ivica Ico Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">Many thanks for this, Albert. Do we also need to disable moving or
move the final deb file that is built into a specific folder? By
default tar_em_up.sh moves it into the one level above the root git
folder (e.g. if your git checkout is in ~/blah, the final deb will
be placed in the ~/ folder).<br>
</div></blockquote></div><br></div><div class="gmail_extra">The binary deb can't be used for a Debian source package anyway. I use tar_em_up.sh with the -F option as a way to build everything and put the install tree into the packages/linux_make/build, from where I can move it into the proper Debian staging directory. So I don't actually use the created tarball either.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">But you're right, moving the tarball one level above the source directory might create issues on Launchpad. It would be nice to have an option to have tar_em_up.sh just populate packages/linux_make/build with everything that goes into the package, without actually building the deb package or tarball. Or at least disable the final step where the package gets moved out of the source directory.<br><br></div><div class="gmail_extra">However, I think that I can figure this out on my own. The relevant part of the tar_em_up.sh script are the lines following the `# finish install` comment, right? So I just need an option which does a full build as usual and then just disables the final steps from there.<br></div><div class="gmail_extra"><br>-- <br><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+AlbertGraef</a></div></div>
</div></div>
<br></div></div><span class="">_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="http://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">http://disis.music.vt.edu/listinfo/l2ork-dev</a><br></span></blockquote></div>
<br>_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="http://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">http://disis.music.vt.edu/listinfo/l2ork-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW: <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+AlbertGraef</a></div></div>
</div>