Re: [PD] autotools

[Christof Ressi]

maybe for MinGW, automake could just pass the right variables to 
makefile.mingw? I could also rework the MinGW makefiles for the externals so 
that they don't depend on pd-lib-builder.


Gesendet: Sonntag, 03. Dezember 2017 um 13:42 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list 
Betreff: Re: [PD] autotools

Yeah, I'm looking into not using libtool actually, partially for this reason. 
We are using it with port audio and port midi, but it's not really required for 
things which are only statically linked in the project. The dll we could leave 
as something we do more by hand as we (you!) have worked out the set of steps 
needed.
 
it's recommended to only use libtool for when it's actually necessary and this 
is really for building cross-platform shared libraries. It will be great for 
libpd, for instance, but I'm thinking now we don't really need it for desktop 
Pd.

 

On Dec 3, 2017, at 1:39 PM, Christof Ressi 
mailto:christof.re...@gmx.at]> wrote: 

Yeah and that's largely due to the current layout being recursive,
hmmm.. I don't think that's the reason. currently, there aren't that many 
Makefiles: /src, /portaudio, /portmidi, /asio, /extra and for each external. 
aside from that, my build system is also recursive (calling make on 
pd-lib-builder makefiles for the externals). 
what's really slow is compiling the individual source files. while a typical .c 
file in /src takes ~1 second on my build system, it takes significantly longer 
with libtool. this is easily noticeable when watching the console output. I 
think it's rather an overhead introduced by libtool but I might be wrong. did 
you notice that on other platforms?  


Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] autotools

[Dan Wilcox]

Yeah, I'm looking into not using libtool actually, partially for this reason. 
We are using it with port audio and port midi, but it's not really required for 
things which are only statically linked in the project. The dll we could leave 
as something we do more by hand as we (you!) have worked out the set of steps 
needed.

it's recommended to only use libtool for when it's actually necessary and this 
is really for building cross-platform shared libraries. It will be great for 
libpd, for instance, but I'm thinking now we don't really need it for desktop 
Pd.

> On Dec 3, 2017, at 1:39 PM, Christof Ressi  wrote:
> 
>> Yeah and that's largely due to the current layout being recursive,
> 
> hmmm.. I don't think that's the reason. currently, there aren't that many 
> Makefiles: /src, /portaudio, /portmidi, /asio, /extra and for each external. 
> aside from that, my build system is also recursive (calling make on 
> pd-lib-builder makefiles for the externals). 
> what's really slow is compiling the individual source files. while a typical 
> .c file in /src takes ~1 second on my build system, it takes significantly 
> longer with libtool. this is easily noticeable when watching the console 
> output. I think it's rather an overhead introduced by libtool but I might be 
> wrong. did you notice that on other platforms? 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] autotools

[Christof Ressi]

> Yeah and that's largely due to the current layout being recursive,

hmmm.. I don't think that's the reason. currently, there aren't that many 
Makefiles: /src, /portaudio, /portmidi, /asio, /extra and for each external. 
aside from that, my build system is also recursive (calling make on 
pd-lib-builder makefiles for the externals). 
what's really slow is compiling the individual source files. while a typical .c 
file in /src takes ~1 second on my build system, it takes significantly longer 
with libtool. this is easily noticeable when watching the console output. I 
think it's rather an overhead introduced by libtool but I might be wrong. did 
you notice that on other platforms? 


Gesendet: Sonntag, 03. Dezember 2017 um 12:55 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list , "Miller Puckette" 
Betreff: Re: [PD] autotools

 

On Dec 3, 2017, at 11:39 AM, Christof Ressi 
mailto:christof.re...@gmx.at]> wrote: 
but most other platform specific knowledge will be the same for any build 
system I guess. after all, Pd changes in a slow and healthy pace, so there 
aren't many modifications to be done to the build system once it is set up.
 
That is definitely true. Automake puts together the makefile rules for you but 
of course it still works in the same way in the end.
 
I've also found this guide to be pretty helpful in the getting into the basics: 
https://autotools.io/index.html[https://autotools.io/index.html]
 
the one thing I noticed is build speed: a complete rebuild (including 
externals) on my personal MinGW build system takes ~40 seconds but with 
autotools it takes a whopping 4 minutes and 30 seconds!
 
Yeah and that's largely due to the current layout being recursive, ie. multiple 
makefiles in multiple directories. This is one of the reasons there have been 
some projects that rework things into a single main makefile as it lowers the 
amount of directory walking and intermediate steps ie. non-recursive make: 
https://autotools.io/automake/nonrecursive.html[https://autotools.io/automake/nonrecursive.html]
 
To some degree, configure will always be slow for all sorts of reasons, but 
there are definitely techniques to slow down the make process. Another 
advantage to non-recursive make is that doing a parallel build would work 
without timing uncertainties between different makefiles. 


Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] autotools

[Dan Wilcox]

> On Dec 3, 2017, at 11:39 AM, Christof Ressi  wrote:
> 
> but most other platform specific knowledge will be the same for any build 
> system I guess. after all, Pd changes in a slow and healthy pace, so there 
> aren't many modifications to be done to the build system once it is set up.

That is definitely true. Automake puts together the makefile rules for you but 
of course it still works in the same way in the end.

I've also found this guide to be pretty helpful in the getting into the basics: 
https://autotools.io/index.html 

> the one thing I noticed is build speed: a complete rebuild (including 
> externals) on my personal MinGW build system takes ~40 seconds but with 
> autotools it takes a whopping 4 minutes and 30 seconds!

Yeah and that's largely due to the current layout being recursive, ie. multiple 
makefiles in multiple directories. This is one of the reasons there have been 
some projects that rework things into a single main makefile as it lowers the 
amount of directory walking and intermediate steps ie. non-recursive make: 
https://autotools.io/automake/nonrecursive.html 


To some degree, configure will always be slow for all sorts of reasons, but 
there are definitely techniques to slow down the make process. Another 
advantage to non-recursive make is that doing a parallel build would work 
without timing uncertainties between different makefiles.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] autotools

[Christof Ressi]

some comments from someone who very recently got into autotools. my personal 
problem was that I thought just because automake generates makefiles, it would 
be similar to make syntax. after I understood it's a totally different system 
and followed some tutorials, I think it's not so hard. there are some quirks 
like getting the right flags for libtool to produce proper Windows DLLs, 
tricking libtool to link with g++ for ASIO etc. but most other platform 
specific knowledge will be the same for any build system I guess. after all, Pd 
changes in a slow and healthy pace, so there aren't many modifications to be 
done to the build system once it is set up.

the one thing I noticed is build speed: a complete rebuild (including 
externals) on my personal MinGW build system takes ~40 seconds but with 
autotools it takes a whopping 4 minutes and 30 seconds!

> 2. hybrid autoconf/makefile: If we want, we can use regular makefile rules in 
> automake files or our own makefiles instead of automake 
> and simply use the configuration variables for autoconf. 

that could also be a good solution. ./configure is definitly great to have!

anyway, just some thoughts, I don't have any real opinion. I'm willing to work 
on whatever build system we finally get.

Gesendet: Sonntag, 03. Dezember 2017 um 03:58 Uhr
Von: "Dan Wilcox" 
An: pd-list 
Cc: "Miller Puckette" 
Betreff: [PD] autotools

I started working on the pd autotools build mainly because I had already used 
autotools before and it seemed like the easiest way to get Pd to build on macOS 
again. So far, we've moved forward with it in general, but at this point I 
wonder if a re-examination makes sense.
 
Some points:
 
1. ./configure && make are great for users -> The more people who can easily 
build Pd, the more help we can get for all sorts of things. I think we've been 
seeing that the last 6 months or so.
 
2. Built-in support for gettext processing, standard install targets, etc allow 
for translations and package management (Debian)
 
3. *Maintaining* the configure.ac & Makefile.am files makes maintaining the 
build system relatively easy, if you understand it (see next point).
 
4. *Developing* the autotools build system is a PITA. There are a lot of 
details and basic understanding required in order to both make sense and use it 
effectively. Once everything works, it's *great* (point 1), but sometimes 
getting there takes a while. Also, fewer people are willing to help with it 
because of the overhead.
 
Pd is in some ways both a simple and a complex project to build. Simple in that 
C is easy to build anywhere and TCL just needs things in the right place. It's 
complex in that Pd builds and runs on a variety of platforms, each with it's 
own peculiarities.
 
The original makefile build system works relatively well for the simple cases 
while the autotools build system works for the complexities (while requiring 
complexity). The makefiles are straightforward and easy to understand at a loss 
in flexibility while ./configure et al are black boxes that support lots of 
configuration options and hopefully work most of the time.
 
When I did the overhaul last year, I went through and added documentation to 
the various Makefile.ams and the configure.ac  to help in understanding things, 
but I think that it's still down to IOhannes and I to do any sort of work on 
the setup as it is. I'm not sure if that is healthy in the long run.
 
I'm thinking now about about different approaches to simplify what is there:
 
1. non-recursive automake: a single large Makefile.am without the various files 
in subfolders. There are a number of advantages to this including build speed, 
putting things in one place, etc.
 
2. hybrid autoconf/makefile: If we want, we can use regular makefile rules in 
automake files or our own makefiles instead of automake and simply use the 
configuration variables for autoconf. This would allow for exposing more of the 
core build information in a readable way at the expense of perhaps higher 
maintenance.
 
The autotools are definitely useful but I admit can be a bit of a beast (but 
this guide helps a great deal: https://autotools.io/index.html). OTOH I would 
argue that *any* build system can be a beast, especially for a cross-platform 
project. In either case, I don't think we want to end up with a 
"non-understandable black box mess" and I'm thinking of ways to make things 
easy to work with for both Pd users *and* developers.
 


Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 ___ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]

[PD] autotools

[Dan Wilcox]

I started working on the pd autotools build mainly because I had already used 
autotools before and it seemed like the easiest way to get Pd to build on macOS 
again. So far, we've moved forward with it in general, but at this point I 
wonder if a re-examination makes sense.

Some points:

1. ./configure && make are great for users -> The more people who can easily 
build Pd, the more help we can get for all sorts of things. I think we've been 
seeing that the last 6 months or so.

2. Built-in support for gettext processing, standard install targets, etc allow 
for translations and package management (Debian)

3. *Maintaining* the configure.ac & Makefile.am files makes maintaining the 
build system relatively easy, if you understand it (see next point).

4. *Developing* the autotools build system is a PITA. There are a lot of 
details and basic understanding required in order to both make sense and use it 
effectively. Once everything works, it's *great* (point 1), but sometimes 
getting there takes a while. Also, fewer people are willing to help with it 
because of the overhead.

Pd is in some ways both a simple and a complex project to build. Simple in that 
C is easy to build anywhere and TCL just needs things in the right place. It's 
complex in that Pd builds and runs on a variety of platforms, each with it's 
own peculiarities.

The original makefile build system works relatively well for the simple cases 
while the autotools build system works for the complexities (while requiring 
complexity). The makefiles are straightforward and easy to understand at a loss 
in flexibility while ./configure et al are black boxes that support lots of 
configuration options and hopefully work most of the time.

When I did the overhaul last year, I went through and added documentation to 
the various Makefile.ams and the configure.ac  to help in understanding things, 
but I think that it's still down to IOhannes and I to do any sort of work on 
the setup as it is. I'm not sure if that is healthy in the long run.

I'm thinking now about about different approaches to simplify what is there:

1. non-recursive automake: a single large Makefile.am without the various files 
in subfolders. There are a number of advantages to this including build speed, 
putting things in one place, etc.

2. hybrid autoconf/makefile: If we want, we can use regular makefile rules in 
automake files or our own makefiles instead of automake and simply use the 
configuration variables for autoconf. This would allow for exposing more of the 
core build information in a readable way at the expense of perhaps higher 
maintenance.

The autotools are definitely useful but I admit can be a bit of a beast (but 
this guide helps a great deal: https://autotools.io/index.html 
<https://autotools.io/index.html>). OTOH I would argue that *any* build system 
can be a beast, especially for a cross-platform project. In either case, I 
don't think we want to end up with a "non-understandable black box mess" and 
I'm thinking of ways to make things easy to work with for both Pd users *and* 
developers.


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] autotools, fonts, etc

[Dan Wilcox]

Ok, I put the current info on the wiki: 
https://github.com/pure-data/pure-data/wiki/Building-Pd-&-the-various-WIP-branches
 
<https://github.com/pure-data/pure-data/wiki/Building-Pd-&-the-various-WIP-branches>

> On Feb 15, 2017, at 9:27 AM, me.grimm  wrote:
> 
> Thanks Dan. Very clear and concise...
> 
> Maybe your instructions should go on WIki once all ironed out:
> 
> https://github.com/pure-data/pure-data/wiki 
> <https://github.com/pure-data/pure-data/wiki>
> 
> there seems to be nothing there but am assuming this is a better place that 
> puredata.info <http://puredata.info/> ... which is probably a whole other 
> discussion
> 
> cheers
> m
> 
> 
> 
> On Wed, Feb 15, 2017 at 11:11 AM, Dan Wilcox  <mailto:danomat...@gmail.com>> wrote:
> I plan to update the install.txt with up to date info on how to build Pd.
> 
> master branch
> ---
> 
> In the meantime, the steps to build from a git clone of master are:
> 
> ./autogen.sh
> ./configure
> make
> 
> By default, it will build for the current platform architecture, usually 64 
> bit. If you want 32 bit, add this configure flag before making:
> 
> ./configure --enable-universal=i386
> 
> To build a mac app, you would normally be able to run “make app” but, as I 
> mentioned in my previous email, there is currently a bug, so you should call 
> the app builder script directly:
> 
> cd mac
> osx-app.sh -i 0.47.1
> 
> osx-app-fix branch
> 
> 
> The app builder problem is fixed in the osx-app-fix branch if someone wants 
> to merge that.
> 
> osx-retina-support branch
> --
> 
> For those that want to experiment with building Pd for a newer Tk 8.6 
> Wish.app, you can install my test builds from 
> http://docs.danomatika.com/pdbuilds/ <http://docs.danomatika.com/pdbuilds/>
> Otherwise, you can build from the branch directly (in this case for 32 bit):
> 
> git clone https://github.com/pure-data/pure-data.git 
> <https://github.com/pure-data/pure-data.git> -b osx-retina-support
> cd pure-data
> ./configure  --enable-universal=i386
> make
> 
> Now that Pd is built, you can either build the mac app using the included Tk 
> 8.4 Wish via:
> 
> make app
> 
> Of you can build a Wish.app for a newer version of Tcl/Tk and use that 
> instead. To do this, you have to call the scripts manually instead of through 
> make (the following downloads and builds a 32bit Tk 8.6.5 Wish.app and uses 
> that to create the Pd app):
> 
> mac/tcltk-wish.sh --arch i386 8.6.5
> mac/osx-app.sh --wish Wish-8.6.5.app 0.47.1
> 
> Both scripts have extensive help which you can check via:
> 
> mac/tcltk-wish.sh --help
> mac/oex-app.sh --help
> 
> dejavu branch
> --
> 
> I put the prelim font work in a branch called “dejavu” from the master 
> branch. It currently only has changes on Mac and bundles the font inside the 
> .app when you build the Pd .app.
> 
>> On Feb 15, 2017, at 6:09 AM, pd-list-requ...@lists.iem.at 
>> <mailto:pd-list-requ...@lists.iem.at> wrote:
>> 
>> From: "me.grimm" mailto:megr...@gmail.com>>
>> Subject: [PD] autotools, fonts, etc
>> Date: February 15, 2017 at 6:09:48 AM MST
>> To: "pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" 
>> mailto:pd-list@lists.iem.at>>
>> 
>> 
>> some of these threads are getting too complicated to keep up on
>> 
>> can we get some clarity which i guess could be answered with a "yes/no":
>> 
>> so Dans osx retina/autotools changes are now at github so:
>> 
>> $ git clone https://github.com/pure-data/pure-data.git 
>> <https://github.com/pure-data/pure-data.git> 
>>  
>> config, make, etc
>> 
>> $ cd mac
>> $ osx-app.sh -i 0.47.1
>> 
>> should do it...
>> 
>> 
>>  and i assume all the font stuff getting discussed is not part of this
>> 
>> m
> 
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
> 
> 
> 
> 
> 
> 
> -- 
> 
> m.e.grimm, m.f.a, ed.m.
> syracuse u., tc3
> megrimm.net <http://megrimm.net/>
> 


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] autotools, fonts, etc

[me.grimm]

Thanks Dan. Very clear and concise...

Maybe your instructions should go on WIki once all ironed out:

https://github.com/pure-data/pure-data/wiki

there seems to be nothing there but am assuming this is a better place that
puredata.info ... which is probably a whole other discussion

cheers
m



On Wed, Feb 15, 2017 at 11:11 AM, Dan Wilcox  wrote:

> I plan to update the install.txt with up to date info on how to build Pd.
>
> master branch
> ---
>
> In the meantime, the steps to build from a git clone of master are:
>
> ./autogen.sh
> ./configure
> make
>
> By default, it will build for the current platform architecture, usually
> 64 bit. If you want 32 bit, add this configure flag before making:
>
> ./configure --enable-universal=i386
>
> To build a mac app, you would normally be able to run “make app” but, as I
> mentioned in my previous email, there is currently a bug, so you should
> call the app builder script directly:
>
> cd mac
> osx-app.sh -i 0.47.1
>
> osx-app-fix branch
> 
>
> The app builder problem is fixed in the osx-app-fix branch if someone
> wants to merge that.
>
> osx-retina-support branch
> --
>
> For those that want to experiment with building Pd for a newer Tk 8.6
> Wish.app, you can install my test builds from http://docs.danomatika.
> com/pdbuilds/
> Otherwise, you can build from the branch directly (in this case for 32
> bit):
>
> git clone https://github.com/pure-data/pure-data.git -b osx-retina-support
> cd pure-data
> ./configure  --enable-universal=i386
> make
>
> Now that Pd is built, you can either build the mac app using the included
> Tk 8.4 Wish via:
>
> make app
>
> Of you can build a Wish.app for a newer version of Tcl/Tk and use that
> instead. To do this, you have to call the scripts manually instead of
> through make (the following downloads and builds a 32bit Tk 8.6.5 Wish.app
> and uses that to create the Pd app):
>
> mac/tcltk-wish.sh --arch i386 8.6.5
> mac/osx-app.sh --wish Wish-8.6.5.app 0.47.1
>
> Both scripts have extensive help which you can check via:
>
> mac/tcltk-wish.sh --help
> mac/oex-app.sh --help
>
> dejavu branch
> --
>
> I put the prelim font work in a branch called “dejavu” from the master
> branch. It currently only has changes on Mac and bundles the font inside
> the .app when you build the Pd .app.
>
> On Feb 15, 2017, at 6:09 AM, pd-list-requ...@lists.iem.at wrote:
>
> *From: *"me.grimm" 
> *Subject: **[PD] autotools, fonts, etc*
> *Date: *February 15, 2017 at 6:09:48 AM MST
> *To: *"pd-list@lists.iem.at" 
>
>
> some of these threads are getting too complicated to keep up on
>
> can we get some clarity which i guess could be answered with a "yes/no":
>
> so Dans osx retina/autotools changes are now at github so:
>
> $ git clone https://github.com/pure-data/pure-data.git
>
> config, make, etc
>
> $ cd mac
> $ osx-app.sh -i 0.47.1
>
> should do it...
>
>
>  and i assume all the font stuff getting discussed is not part of this
>
> m
>
>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>


-- 

m.e.grimm, m.f.a, ed.m.
syracuse u., tc3
megrimm.net

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] autotools, fonts, etc

[Dan Wilcox]

> On Feb 15, 2017, at 8:20 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: IOhannes m zmoelnig mailto:zmoel...@iem.at>>
> Subject: Re: [PD] autotools, fonts, etc
> Date: February 15, 2017 at 6:52:03 AM MST
> To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
> 
> you will have to check out the "osx-retina-support" branch (which
> currently lags behind signficantly)

I updated it with master last night. *Pretty* sure I merged all the .tcl 
alt-modifiers changes correctly… :)


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] autotools, fonts, etc

[Dan Wilcox]

I plan to update the install.txt with up to date info on how to build Pd.

master branch
---

In the meantime, the steps to build from a git clone of master are:

./autogen.sh
./configure
make

By default, it will build for the current platform architecture, usually 64 
bit. If you want 32 bit, add this configure flag before making:

./configure --enable-universal=i386

To build a mac app, you would normally be able to run “make app” but, as I 
mentioned in my previous email, there is currently a bug, so you should call 
the app builder script directly:

cd mac
osx-app.sh -i 0.47.1

osx-app-fix branch


The app builder problem is fixed in the osx-app-fix branch if someone wants to 
merge that.

osx-retina-support branch
--

For those that want to experiment with building Pd for a newer Tk 8.6 Wish.app, 
you can install my test builds from http://docs.danomatika.com/pdbuilds/ 
<http://docs.danomatika.com/pdbuilds/>
Otherwise, you can build from the branch directly (in this case for 32 bit):

git clone https://github.com/pure-data/pure-data.git 
<https://github.com/pure-data/pure-data.git> -b osx-retina-support
cd pure-data
./configure  --enable-universal=i386
make

Now that Pd is built, you can either build the mac app using the included Tk 
8.4 Wish via:

make app

Of you can build a Wish.app for a newer version of Tcl/Tk and use that instead. 
To do this, you have to call the scripts manually instead of through make (the 
following downloads and builds a 32bit Tk 8.6.5 Wish.app and uses that to 
create the Pd app):

mac/tcltk-wish.sh --arch i386 8.6.5
mac/osx-app.sh --wish Wish-8.6.5.app 0.47.1

Both scripts have extensive help which you can check via:

mac/tcltk-wish.sh --help
mac/oex-app.sh --help

dejavu branch
--

I put the prelim font work in a branch called “dejavu” from the master branch. 
It currently only has changes on Mac and bundles the font inside the .app when 
you build the Pd .app.

> On Feb 15, 2017, at 6:09 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: "me.grimm" mailto:megr...@gmail.com>>
> Subject: [PD] autotools, fonts, etc
> Date: February 15, 2017 at 6:09:48 AM MST
> To: "pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" 
> mailto:pd-list@lists.iem.at>>
> 
> 
> some of these threads are getting too complicated to keep up on
> 
> can we get some clarity which i guess could be answered with a "yes/no":
> 
> so Dans osx retina/autotools changes are now at github so:
> 
> $ git clone https://github.com/pure-data/pure-data.git 
> <https://github.com/pure-data/pure-data.git> 
>  
> config, make, etc
> 
> $ cd mac
> $ osx-app.sh -i 0.47.1
> 
> should do it...
> 
> 
>  and i assume all the font stuff getting discussed is not part of this
> 
> m


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] autotools, fonts, etc

[IOhannes m zmoelnig]

On 2017-02-15 14:09, me.grimm wrote:
> so Dans osx retina/autotools changes are now at github so:

i don't think the retina-changes have been merged into master (unlike
the autotools changes, which have).
you will have to check out the "osx-retina-support" branch (which
currently lags behind signficantly)

fgams
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] autotools, fonts, etc

[me.grimm]

some of these threads are getting too complicated to keep up on

can we get some clarity which i guess could be answered with a "yes/no":

so Dans osx retina/autotools changes are now at github so:

$ git clone https://github.com/pure-data/pure-data.git

config, make, etc

$ cd mac
$ osx-app.sh -i 0.47.1

should do it...


 and i assume all the font stuff getting discussed is not part of this

m
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[IOhannes m zmölnig]

On 04/13/2016 05:12 PM, Dan Wilcox wrote:
> I found that confusing too. Maybe we should make that a conditional in the 
> configure.ac.
> 

implemented in the attached patch.

gfmdsar
IOhannes

From 88b4a7f3f6eb07ffe7541350e290ad3d884ebaaa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?IOhannes=20m=20zm=C3=B6lnig?=
 
Date: Tue, 26 Apr 2016 23:40:45 +0200
Subject: [PATCH 1/3] only run portaudio's configure if it has not been
 disabled

---
 configure.ac | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index a263e0c..fbcc5a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5,10 +5,6 @@ AC_CONFIG_AUX_DIR([m4/config])
 AM_INIT_AUTOMAKE
 AC_CONFIG_MACRO_DIR([m4/generated])
 
-if test -d "$srcdir/portaudio"; then
-  AC_CONFIG_SUBDIRS([portaudio])
-fi
-
 
 AC_CANONICAL_HOST
 
@@ -203,13 +199,22 @@ AC_ARG_ENABLE([portaudio],
 	[portaudio=$enableval])	
 AM_CONDITIONAL(PORTAUDIO, test x$portaudio = xyes)
 
+AS_IF([test x$portaudio = xyes], [
+ AS_IF([test -d "$srcdir/portaudio" ], [
+  AC_CONFIG_SUBDIRS([portaudio])
+ ])
+])
+
+
 dnl portmidi
 AC_ARG_ENABLE([portmidi],
 	[AS_HELP_STRING([--enable-portmidi],
 		[use portmidi])],
 [portmidi=$enableval])
 AM_CONDITIONAL(PORTMIDI, test x$portmidi = xyes)
-if test x$portmidi = xyes; then echo Using included portmidi; fi
+AS_IF([test x$portmidi = xyes], [
+ AC_MSG_NOTICE([using included portmidi])
+])
 
 dnl fftw v3
 AC_ARG_ENABLE([fftw],
-- 
2.8.1



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[IOhannes m zmölnig]

On 04/26/2016 06:53 PM, Derek Kwan wrote:
> This is somewhat related... I haven't updated to the new Ubuntu 16.04
> LTS yet (still on 15.10), but are there plans of doing snappy packages
> as well as debs?

not from my side.

gfmadsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[Derek Kwan]

> > apt-get build-dep puredata
> > finds no puredata source package
> 
> you probably need a `deb-src` line in your /etc/apt/sources.lists file.
> 

This is somewhat related... I haven't updated to the new Ubuntu 16.04
LTS yet (still on 15.10), but are there plans of doing snappy packages
as well as debs?

Derek

=
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[IOhannes m zmoelnig]

On 2016-04-26 05:14, Billy Stiltner wrote:
> apt-get build-dep puredata
> finds no puredata source package

you probably need a `deb-src` line in your /etc/apt/sources.lists file.

sthg like:

deb http://httpredir.debian.org/debian jessie main
deb-src http://httpredir.debian.org/debian jessie main


fgmasdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[Billy Stiltner]

not dial but knob rather
. couldn't create
 ext/knob 12 12 -12 12 0 0 $0-o1-dt-knob $0-o1-dt-rx-knob tune 0 7 0 6
-262144 -258113 -261234 550 1
so it is an error on my end for not having a knob available
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[Billy Stiltner]

after the dependencies were installed
the autogen script worked as well as configure with no arguments
after a make install
and running with

make[1]: Leaving directory '/home/billy/src/pd-0.47-0test2'
root@debian:/home/billy/src/pd-0.47-0test2# pd

i can load the clone help patch and it seems to be working
audio sounds a bit thin playing xensynth
was getting conflicting block error while the help objects page was open
closed, listened to xensynth on 0.47-3 installed from synaptic
sounds so good
not sure why the audio would be thin sounding on test 02
it's that the dial patch is missing probably and xensynth uses the controls
as part of
the preset loading and adjustment so probably nothing to do with the code
there are no conflicting block size errors without the  object help patch
open


On Mon, Apr 25, 2016 at 11:25 PM, Miller Puckette  wrote:

> Dunno...
>
> WHat I do is:
>
> Download Pd source and untar (making pd-0.47-0test2, for example)
> cd pd-0.47-0test2/src
> make -f makefile.gnu
>
> Almost always works and if not it's because I forgot to install
> libasound2-dev etc as in the INSTALL.txt file.
>
> cheers
> Miller
>
> On Mon, Apr 25, 2016 at 11:14:09PM -0400, Billy Stiltner wrote:
> > maybe it's where i'm new to plain ol debian
> > and using it instead of ubuntu
> > changed the repositories to stretch then upgraded the
> > packages that were not 0.47-3 to 0.47-3
> > works great, seen the 0.47test2 thing and wanted to try the
> > clone thing.
> > logged in with fresh non root user
> > apt-get build-dep puredata
> > finds no puredata source package
> > logged in as root its probably upgrading half of the debian installation
> > how does being logged in as root affect make , autogen.sh, and configure?
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[Miller Puckette]

Dunno...

WHat I do is:

Download Pd source and untar (making pd-0.47-0test2, for example)
cd pd-0.47-0test2/src
make -f makefile.gnu

Almost always works and if not it's because I forgot to install
libasound2-dev etc as in the INSTALL.txt file.

cheers
Miller

On Mon, Apr 25, 2016 at 11:14:09PM -0400, Billy Stiltner wrote:
> maybe it's where i'm new to plain ol debian
> and using it instead of ubuntu
> changed the repositories to stretch then upgraded the
> packages that were not 0.47-3 to 0.47-3
> works great, seen the 0.47test2 thing and wanted to try the
> clone thing.
> logged in with fresh non root user
> apt-get build-dep puredata
> finds no puredata source package
> logged in as root its probably upgrading half of the debian installation
> how does being logged in as root affect make , autogen.sh, and configure?

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[Billy Stiltner]

maybe it's where i'm new to plain ol debian
and using it instead of ubuntu
changed the repositories to stretch then upgraded the
packages that were not 0.47-3 to 0.47-3
works great, seen the 0.47test2 thing and wanted to try the
clone thing.
logged in with fresh non root user
apt-get build-dep puredata
finds no puredata source package
logged in as root its probably upgrading half of the debian installation
how does being logged in as root affect make , autogen.sh, and configure?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[Dan Wilcox]

I found that confusing too. Maybe we should make that a conditional in the 
configure.ac.

> On Apr 13, 2016, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
> Pd's ./configure script recusively calls the configure script in the
> portaudio/ folder (even if you specifify '--disable-portaudio'¹), and
> the output you are seeing is from portaudio's configure.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[IOhannes m zmölnig]

On 04/13/2016 12:09 AM, Billy Stiltner wrote:
> building 0.46-7 on jessie
> somehow it works now for --disable-portaudio
[...]
> I'll just switch to test and updater
> Configuration summary:
> 
>   Target .. x86_64-unknown-linux-gnu
>   C++ bindings  no
>   Debug output  no
> 
>   ALSA  no
>   ASIHPI .. no
> 
>   OSS . yes
>   JACK  no
> 
> billy@debian:~/src/pd-0.46-7$

unfortunately this is *not* the configuration summary.
Pd's ./configure script recusively calls the configure script in the
portaudio/ folder (even if you specifify '--disable-portaudio'¹), and
the output you are seeing is from portaudio's configure.

> but with --enable-alsa I have no alsa

specifying '--enable-alsa' doesn't magically enable ALSA: you will
*also* need the alsa development files installed.

(as mentioned numerous times on this list) a *very* good start to
building Pd on Debian-like systems is to install all the tools needed to
build the official "puredata" Debian package:

apt-get build-dep puredata

another trick (also mentioned a few times on this list; iirc at least
once in direct reply to an email from you ;-)) is that mostly you can
build another version of a package "the Debian way":

$ sudo apt-get install devscripts
$ dget
http://ftp.de.debian.org/debian/pool/main/p/puredata/puredata_0.46.7-3.dsc
$ cd puredata-0.46.7
$ mk-build-deps -i -r -s sudo
$ dpkg-buildpackage -rfakeroot
$ sudo dpkg -i ../*_0.46.7-*.deb

mgfasdr
IOhannes

¹ portaudio/configure is called, but the resulting Pd binary is built
without portaudio.



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[Billy Stiltner]

building 0.46-7 on jessie
somehow it works now for --disable-portaudio
but with --enable-alsa I have no alsa
I'll just switch to test and updater
Configuration summary:

  Target .. x86_64-unknown-linux-gnu
  C++ bindings  no
  Debug output  no

  ALSA  no
  ASIHPI .. no

  OSS . yes
  JACK  no

billy@debian:~/src/pd-0.46-7$


On Tue, Apr 12, 2016 at 12:37 AM, IOhannes m zmölnig 
wrote:

> On 04/12/2016 12:00 AM, Billy Stiltner wrote:
> > ./configure --disable-jack --disable-portaudio
> >
> > configure fails for portaudio
>
> what does "fails" mean? which version of Pd?
>
> since Debian ships with Pd-0.46-7 and it's build process uses the
> cmdline you gave (jessie ships Pd-0.46-2, but that shouldn't much
> differ), i somewhat doubt that this is really broken.
>
> gfmrdsa
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD autotools on debian 8.4 broke

[IOhannes m zmölnig]

On 04/12/2016 12:00 AM, Billy Stiltner wrote:
> ./configure --disable-jack --disable-portaudio
> 
> configure fails for portaudio

what does "fails" mean? which version of Pd?

since Debian ships with Pd-0.46-7 and it's build process uses the
cmdline you gave (jessie ships Pd-0.46-2, but that shouldn't much
differ), i somewhat doubt that this is really broken.

gfmrdsa
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD autotools on debian 8.4 broke

[Billy Stiltner]

./configure --disable-jack --disable-portaudio

configure fails for portaudio
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list