[L2Ork-dev] compiling pd-l2Ork from source

[Ivica Bukvic]

Good catch. I will remove those from the repo asap.
On Nov 13, 2014 8:34 AM, "Albert Graef" <aggraef at gmail.com> wrote:

> 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
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20141113/74da3703/attachment-0001.html>