[L2Ork-dev] compiling pd-l2Ork from source

[Albert Graef]

Testing with pbuilder-dist right now. Still fighting with some of the build
dependencies, but Lintian also tells me about some broken links in the
source repository, so I thought I might just as well report these right
away:

E: pd-l2ork source: source-contains-unsafe-symlink
externals/grill/trunk/flext/config.guess
E: pd-l2ork source: source-contains-unsafe-symlink
externals/grill/trunk/flext/config.sub
E: pd-l2ork source: source-contains-unsafe-symlink
externals/grill/trunk/flext/depcomp
E: pd-l2ork source: source-contains-unsafe-symlink
externals/grill/trunk/flext/install-sh
E: pd-l2ork source: source-contains-unsafe-symlink
externals/grill/trunk/flext/ltmain.sh
E: pd-l2ork source: source-contains-unsafe-symlink
externals/grill/trunk/flext/missing

I'd remove these from the repository (AFAICT they're generated anyway).

Lintian also complains about these binaries in the repository:

E: pd-l2ork source: source-is-missing
externals/postlude/pluginhost~/libpluginhost~.so
E: pd-l2ork source: source-is-missing
doc/additional/pd-msg/3.pdscript/pdsend

These are surely generated as well, in any case they shouldn't be in the
repository either.


On Thu, Nov 13, 2014 at 4:47 AM, Albert Graef <aggraef at gmail.com> wrote:

> 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.
>
> 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.
>
> Albert
>
> On Wed, Nov 12, 2014 at 2:40 PM, Ivica Bukvic <ico at vt.edu> wrote:
>
>> 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
>> On Nov 12, 2014 8:25 AM, "Albert Graef" <aggraef at gmail.com> wrote:
>>
>>> On Wed, Nov 12, 2014 at 4:04 AM, Ivica Ico Bukvic <ico at vt.edu> wrote:
>>>
>>>> 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).
>>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> --
>>> Dr. Albert Gr"af
>>> Computer Music Research Group, JGU Mainz, Germany
>>> Email:  aggraef at gmail.com
>>> WWW:    https://plus.google.com/+AlbertGraef
>>>
>>> _______________________________________________
>>> L2Ork-dev mailing list
>>> L2Ork-dev at disis.music.vt.edu
>>> http://disis.music.vt.edu/listinfo/l2ork-dev
>>>
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> http://disis.music.vt.edu/listinfo/l2ork-dev
>>
>
>
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email:  aggraef at gmail.com
> WWW:    https://plus.google.com/+AlbertGraef
>



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20141113/b3184c35/attachment.html>