headers
Hans-Christoph Steiner | 1 Jul 2010 04:43
Picon
Favicon
Gravatar

Re: flext


The idea is to have all libraries have their own standalone build  
systems that do not rely on the packages/Makefile.buildlayout stuff.   
That's the idea with the Makefile/library template.

I think the best plan for flext would be to make a version of the  
template Makefile that works for C++/flext.  Then that Makefile can  
easily be used for Debian/Ubuntu/RPM/etc. packaging.

http://puredata.info/docs/developer/MakefileTemplate

I could see including the flext library itself in Pd-extended, that is  
if it is not changing much.  But the externals itself should start out  
separately distributed libdirs IMHO.

.hc

On Jun 28, 2010, at 9:50 PM, dmotd wrote:

> hi hans,
>
> the work i've done slots straight into the existing
> externals/Makefile structure and currently builds fine on
> linux, it uses thomas' build system and until a better
> autoconf alternative is created, this is by far the easiest
> (and has been working quite well for years). as such this a
> multi-class single lib system.
>
> i have followed the libdir rules, with help-files
> abstraction (and in py/ext case scriptets) in each libs own
(Continue reading)

Permalink | Reply | 1 comment |
headers
dmotd | 1 Jul 2010 19:03
Picon

Re: flext

hi hans,

okay, i still have no real idea what you are talking about
here? i get the makefile template, but how exactly does this
relate to a buildsystem, the examples that use the template
are still called by the centralised makefile? 

thomas maintains his own buildsystem and as much as its
apparently stumped a bunch of people in the past, it is
designed for cross platform AND max/msp. to redesign an
entire build system to fit a template, for sake of maintaining
some design rules seems a little over the top, that's why i
decided to simply wrap it. besides, the flext layer has enough
complexity to require a decent autoconf first, and if recent
threads are correct, there's no libdir based autoconf
template.

the thing that has me confused is this notion of packaging?
if pd-X is going to disolve into a system of separated libs
(libdirs?) called by a virtual package 'pd-X', and thus
'debianize' the entire system, then i support that - however
there must be some wrapper script that does the job that
pd-X currently does? i understand that the template is
designed to make that job simpler, by making the build
assumptions the responsibility of each lib and creating a
libdir path, but how does this actually spawn packages?

what i like about pd-X is that it unifies a lot of extras
and provides a neat wrapper for the build, so i'm assuming
that your direction will be providing scripts to wrap
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans-Christoph Steiner | 1 Jul 2010 21:36
Picon
Favicon
Gravatar

Re: flext


On Jul 1, 2010, at 12:33 PM, dmotd wrote:

> hi hans,
>
> okay, i still have no real idea what you are talking about
> here? i get the makefile template, but how exactly does this
> relate to a buildsystem, the examples that use the template
> are still called by the centralised makefile?

yes, check ext13 externals/Makefile for example.

> thomas maintains his own buildsystem and as much as its
> apparently stumped a bunch of people in the past, it is
> designed for cross platform AND max/msp. to redesign an
> entire build system to fit a template, for sake of maintaining
> some design rules seems a little over the top, that's why i
> decided to simply wrap it. besides, the flext layer has enough
> complexity to require a decent autoconf first, and if recent
> threads are correct, there's no libdir based autoconf
> template.

A libdir autoconf template would be awesome to have though.  Building  
C or C++ objects for Pd isn't hard.  What about flext makes things so  
complicated?  In the process of making that template Makefile, I  
realized that autotools is really rarely needed for externals.  Only  
really when there are a lot of library dependencies.

> the thing that has me confused is this notion of packaging?
> if pd-X is going to disolve into a system of separated libs
(Continue reading)

Permalink | Reply | 3 comments |
headers
dmotd | 2 Jul 2010 08:06
Picon

Re: flext

Hans-Christoph Steiner wrote:
> yes, check ext13 externals/Makefile for example.

yes yes, i know the makefile template well, what i'm
interested in is more a proposal/example for how different
environments will package these templated libs,
dpkg/rpm/zip/dmg/etc, what wrapper scripts will be needed?
how will modularized libdirs get installed in environments
like mac and windows?

> >thomas maintains his own buildsystem and as much as its
> >apparently stumped a bunch of people in the past, it is
> >designed for cross platform AND max/msp. to redesign an
> >entire build system to fit a template, for sake of maintaining
> >some design rules seems a little over the top, that's why i
> >decided to simply wrap it. besides, the flext layer has enough
> >complexity to require a decent autoconf first, and if recent
> >threads are correct, there's no libdir based autoconf
> >template.
> 
> A libdir autoconf template would be awesome to have though.
> Building C or C++ objects for Pd isn't hard.  What about flext makes
> things so complicated?  In the process of making that template
> Makefile, I realized that autotools is really rarely needed for
> externals.  Only really when there are a lot of library
> dependencies.

flext is a library dependecy!

flext itself is a programming interface to create a standard
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Grill | 2 Jul 2010 15:42

Re: flext

>> A libdir autoconf template would be awesome to have though.
>> Building C or C++ objects for Pd isn't hard.  What about flext makes
>> things so complicated?  In the process of making that template
>> Makefile, I realized that autotools is really rarely needed for
>> externals.  Only really when there are a lot of library
>> dependencies.
>
> flext is a library dependecy!
>
> flext itself is a programming interface to create a standard
> api between pd + max/msp, the library and its headers need
> to be installed in a known path and thus becomes a
> dependency to any library using flext. additionally it has
> optional simd sse/altivec optimizations, and can be extended
> further with sndobj and stk (synthesis tookit).

i guess for a start it would be ok to leave out SIMD as well as sndobj
and STK, although it should definitely be includable later on.
Compilation of the flext library is really straightforward. The few
preprocessor defs should not really require autoconf.

Also, when flext availability within pd-ext is given, most of the
flext-based externals can be built with fixed path settings for the
flext headers and libraries (not requiring autoconf either). py/pyext
and others are notable exceptions, though.

>
> the current flext buildsys compiles the libs reliant on
> flext from a single build script, using definitions set in
> each libs src folder (package.txt), thus each lib is aware
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans-Christoph Steiner | 2 Jul 2010 23:00
Picon
Favicon
Gravatar

Re: flext


On Jul 2, 2010, at 2:06 AM, dmotd wrote:

> Hans-Christoph Steiner wrote:
>> yes, check ext13 externals/Makefile for example.
>
> yes yes, i know the makefile template well, what i'm
> interested in is more a proposal/example for how different
> environments will package these templated libs,
> dpkg/rpm/zip/dmg/etc, what wrapper scripts will be needed?

Check out the template library mentioned in the MakefileTemplate page,  
it is a working debian package. I'm currently working with someone to  
make it do RPMs too.  Also, all of the libs mentioned in that page are  
also debian packages.

> how will modularized libdirs get installed in environments
> like mac and windows?

Take your pick:

a) run 'make' then zip up the folder for people to copy into ~/Library/ 
Pd, ~/pd-externals, etc.
b) run 'make' then copy the library folder in ~/Library/Pd, ~/pd- 
externals, etc.
c) run 'make install' and it'll install into ~/Library/Pd, ~/pd- 
externals, etc.

>>> thomas maintains his own buildsystem and as much as its
>>> apparently stumped a bunch of people in the past, it is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pierre-Olivier Boulant | 3 Jul 2010 00:10
Picon
Favicon

Re: Join the Compile Farm (was Re: 64-bit build for, Windows?)

Hello everyone,

I'm new here. I've offered to help with the Windows 64bit build. I'm 
really new to compiling software, so I'll probalby need some help to get 
started. If you think this is unmanageable for a beginner don't be 
afraid to tell me so. I have some good will and patience, but I don't 
want to waste anyone's time. :)

I'm reading the MinGW-w64 pages on Sourceforge.
I should be looking for a native compiler for w64, but I can't seem to 
find any. I suppose since it's a native compiler I can build it myself. 
Is this correct. Then, should I download a tarball and compile from the 
source?
Otherwise I found what seems to be a native version here:
http://www.drangon.org/mingw/

I cannont find either the MinGW-get installer mentioned on the 32bit 
version of the instructions. I suppose there is nothing similar for the 
64bit version for the time being.

I suppose I have to get Cygwin for compilation too. Anything I should 
pay special attention to concerning this?

Thanks for your help
Pierre-Olivier

On 02/07/2010 22:46, Hans-Christoph Steiner wrote:
>
> A Windows 7 build sounds like a good idea.  The first place to start 
> is getting a MinGW-w64 build environment setup.  If you get that
(Continue reading)

Permalink | Reply | 2 comments |
headers
SourceForge.net | 4 Jul 2010 07:37
Picon
Favicon

[ pure-data-Bugs-3024970 ] pix_film crashes MacMini running OSX 10.5

Bugs item #3024970, was opened at 2010-07-04 05:36
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3024970&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_film crashes MacMini running OSX 10.5

Initial Comment:
I’ve been working on a Puredata patch that uses MIDI input from an external device to control playback of 2
movies that are displayed in a single GEM window. I have been able to get the patch working properly on my own
computer (a 2.53GHz MacBook Pro with OSX 10.6.3) but can’t get it to work on the computer where the patch
needs to run (a 1.66GHz MacMini with OSX 10.5).

I’ve read through the forums and archives and based on the input I have created several version of the
patch (all of them have crashed on the MacMini). I couldn’t find any instance of a bug report documenting
this issue so I decided to add it here.

I’ve posted my code, two different approaches each with the associated full crash reports. In the first
approach I use two separate Gemheads to control the movies; in the second approach I use a single Gemhead to
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 5 Jul 2010 03:08
Picon
Favicon

[ pure-data-Bugs-3025232 ] widget doesn't handle dollarsign variables

Bugs item #3025232, was opened at 2010-07-04 21:08
Message generated for change (Tracker Item Submitted) made by jancsika1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025232&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: widget doesn't handle dollarsign variables

Initial Comment:
If you create [widget button $1-b], the button won't be displayed (as opposed to [widget button b]).

If you create [widget button $0-b], it gets saved with the value of $0 instead of \$0-b.

Same thing happens with the flags: -text "$0-foo", etc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025232&group_id=55736
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 5 Jul 2010 03:11
Picon
Favicon

[ pure-data-Bugs-3025233 ] widget disappears when its canvas is not visible

Bugs item #3025233, was opened at 2010-07-04 21:11
Message generated for change (Tracker Item Submitted) made by jancsika1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025233&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: widget disappears when its canvas is not visible

Initial Comment:
Along with the [widget] object's inability to handle dollarsign variables correctly, this severely
limits the flexibility of the [widget] object.  For example, you can't initialize a [widget]'s values
using loadbang, nor can you use one in an abstraction and send data to it (like you can with [tgl]).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3025233&group_id=55736
Permalink | Reply | 0 comments |

Gmane