[L2Ork-dev] gui port

Thu Jun 23 16:33:43 UTC 2016

Actually, this is an older commit, but still the binaries shouldn't be in
the repo.

On Thu, Jun 23, 2016 at 2:01 PM, Albert Graef <aggraef at gmail.com> wrote:

> Hi Jonathan, after your most recent update there are now two additional
> folders with binaries in your repo (apparently leftovers from a previous
> build), can you please remove these again?
>
> externals/grill/trunk/flext/libbuild/
> externals/grill/trunk/flext/pd-linux/
>
> On Wed, Jun 22, 2016 at 3:15 AM, Jonathan Wilkes <jancsika at yahoo.com>
> wrote:
>
>> Hm... scratch that-- I just synced the libs that had missing files with
>> Pd-l2ork.  I probably missed a commit or two somewhere.
>>
>> Hopefully that will fix the flite issue.
>>
>> Rebuilding now...
>>
>> -Jonathan
>>
>>
>>
>>
>> On Tuesday, June 21, 2016 8:43 PM, Jonathan Wilkes <jancsika at yahoo.com>
>> wrote:
>>
>>
>> Ok, for flite I get the barf below.  I have no idea how to debug this
>> because
>> moocow's build system is incomprehensible to me.
>>
>> The bug ostensibly gets triggered by this call to run configure:
>> (cd ../flite && sh ./configure CFLAGS="-DPD -I/home/user/purr-data/pd/src
>> -Wall -W -ggdb -I/home/user/purr-data/Gem/src
>> -I/home/user/purr-data/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC
>> -O2 -I/sw/include" LDFLAGS=" -L/home/user/purr-data/pd/src
>> -L/home/user/purr-data/pd/bin -L/home/user/purr-data/pd/obj -L/sw/lib"
>> --with-pd-include="/home/user/purr-data/pd/src"
>> --with-pd-dir="/home/user/purr-data/externals/moocow/extended/build.moo"
>> --disable-dependency-tracking  && make clean) || echo "(MOOCOW) Warning:
>> sub-target failed: 'flite.configure_stamp'"
>>
>> But if I navigate to "moocow" after the failure there is no "configure"
>> script.  It's
>> vanished!
>>
>> Any clues?
>>
>> Relevant error from the build below:
>> [...]
>> urr-data/Gem/src -I/home/user/purr-data/externals/pdp/include -DUNIX
>> -Dunix -DDL_OPEN -I/sw/include -I/home/user/purr-data/pd/src
>> -I/home/user/purr-data/pd/src -DPIC"
>> configure: set EXTRA_CPPFLAGS=""
>> configure: set         CFLAGS="-Wall -W -ggdb -fPIC -O2 -fPIC"
>> configure: set        LDFLAGS="-L/home/user/purr-data/pd/src
>> -L/home/user/purr-data/pd/bin -L/home/user/purr-data/pd/obj -L/sw/lib
>> -Wl,-export-dynamic -shared"
>> configure: creating ./config.status
>> config.status: creating config/Makefile
>> gawk: ./confC3jrYM/subs.awk:106:   FS = "
>> gawk: ./confC3jrYM/subs.awk:106:        ^ unterminated string
>> gawk: ./confC3jrYM/subs.awk:106:   FS = "
>> gawk: ./confC3jrYM/subs.awk:106:        ^ syntax error
>> config.status: error: could not create config/Makefile
>> (MOOCOW) Warning: sub-target failed: 'flite.configure_stamp'
>> touch flite.configure_stamp
>> make DESTDIR="" -C ../flite all install || echo "(MOOCOW) Warning:
>> sub-target failed: 'flite.build_stamp'"
>> make[4]: Entering directory `/home/user/purr-data/externals/mooc
>>
>>
>> On Tuesday, June 21, 2016 6:00 PM, Jonathan Wilkes <jancsika at yahoo.com>
>> wrote:
>>
>>
>>
>>
>> > On Tuesday, June 21, 2016 5:49 PM, Albert Graef <aggraef at gmail.com>
>> wrote:
>>
>>
>> > On Tue, Jun 21, 2016 at 4:02 AM, Jonathan Wilkes <jancsika at yahoo.com>
>> > wrote:
>>
>> In this process I've been extremely cautious about doing anything
>> whatsoever
>> to the build scripts.  It's the most brittle thing I've ever seen, and
>> after more
>> than six months I still don't have a mental model of how it works.
>>
>>
>> > Well, the stuff which does most of the heavy dispatching is in
>> tar_em_up.sh,
>> > packages/linux_make/Makefile and externals/Makefile, AFAICT. This could
>> > really be tidied up a bit some time, but as it works, I don't consider
>> this a high
>> > priority.
>>
>> There is also packages/Makefile and packages/Makefile.buildlayout.  Plus
>> the miXed build nest is incomprehensible.
>>
>> I agree none of that is a priority.
>>
>> However, there is one thing-- I ported cyclone/Scope~.c, which uses the
>> new
>> gui API that isn't in normal Pd-l2ork.  What's the best way to handle
>> that?
>>
>> Someone on the nw.js group said they were working on a ppa a few months
>> back, but I haven't heard anything else about it.
>>
>>
>> > They probably read the Ubuntu packaging guide and instantly became Arch
>> > converts. :) Seriously, Debian packaging is getting old-school and
>> horribly
>> > bloated. It's a breeze for end users and a royal pita for maintainers.
>> Arch's
>> > pacman is the other way round, :) but fortunately there are nice
>> frontends like
>> > Manjaro's pamac to make it usable for Arch noobs.
>>
>> Actually, I'm using pacman to build on Windows-- see the build
>> instructions
>> in README.md.
>>
>>
>> If packaging nw.js is something you'd like to investigate further, please
>> do.
>>
>>
>> > There are better things I can do to waste my time, thank you. :) My
>> idea is to
>> > just include the binary nw.js tarballs with the Debian source package
>> and be
>> > done with it. I vaguely recall that there are ways to do this, but it's
>> been a
>> > while I needed this, so I just need some time to get this sorted out.
>>
>> That sounds good to me.
>>
>> > Meanwhile, I modified my Arch PKGBUILD for pd-l2ork so that it works
>> with
>> > purr-data. The build goes through fine now, but I noticed that just a
>> few
>> > externals and help patches have gone missing in purr-data (see attached
>> > purr-missing-externals.diff). Did you exclude these on purpose, or do I
>> need to
>> > go digging why these don't get included?
>>
>> I'll investigate...
>>
>> -Jonathan
>>
>>
>> It's available-- go to git.purrdata.net and click "all".
>>
>>
>> > Ah yes, thanks! Still need to find my way around on GitLab. :)
>>
>> Cheers,
>>
>> Albert
>>
>> --
>> 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
>

-- 
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/20160623/4f23bfb2/attachment.html>