On Oct 19, 2020, at 3:14 AM, Alexandre Torres Porres porres@gmail.com wrote:

Em dom., 18 de out. de 2020 às 07:09, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu: Newer macOS versions can't run 32 bit code and so the compiler, as far as I know, won't build 32 bit versions. If you are running macOS 10.15, which I believe you are, you cannot build for 32 bit anymore.

I'm in 10.14.6 actually

Ok, so 32 bit compilation should not be an issue. It's also one reason why I am still on 10.14 for now.

In any case, you may have to move to a dedicated build machine which stays on an older version of macOS, say 10.14, if you personal machine is to run the latest version.

no problem, here I am and I should keep it that way :)

so, what does this change? What do I have to do?

It just means you have to tell pdlibuild you want a "fat binary." This used to be the default but Katja updated pdlibbuilder 0.6 to use the system architecture. This is the same approach used by Xcode for some time and is required as trying to build for i386 will just fail on macOS 10.15+.

It might need to be better documented in the README, but you just have to set the fat binary extension when building on macOS (and not other platforms) in your makefile:

extension=d_fat

On a side note, who does still use 32 bits on mac and why? I assume is mostly because you may want to run old externals that are only available for 32 bits, right? If so, I wonder which libraries are actually relevant and if we should just try and build them for 64 bits... since from 10.15 and on they can't even run any more (if I got things correctly).

Mmm yes and no. There are plenty of people using older machines around so its not like there are *no* users of 32 bit Pd. However, I think the numbers have definitely shifted over time as we have 64 bit builds of Pd available and many of the most used externals form extended have been updated and released in 64 bit.

It's really up to how much maintenance can you support for systems you and your team may not use personally. I think it's reasonable to find a point to where you stop 32 bit builds and only move forward with 64 bit releases. If there is no additional work for y'all to unofficial support compiling in 32 bit and the sources are available, people can also make 32 bit builds as required. This is why the decentralized model for externals is great, even if it's taken more time to get things going after extended.

That being said, modern Pd is compilable on Windows XP so who knows who is using your 32 bit builds. :) It's up to you.

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

On 10/19/20 6:24 PM, Alexandre Torres Porres wrote:

Em seg., 19 de out. de 2020 às 06:31, Dan Wilcox danomatika@gmail.com escreveu:

...

you just have to set the fat binary extension when building on macOS (and not other platforms) in your makefile:

extension=d_fat

Tried in the makefile and it didn't work, but then I thought you may have meant when doing "make install" and it worked ;)

i don't know what you tested. but you should pass the "extension=..." argument to all invocations of make, like so:

make extension=d_fat
make extension=d_fat install

otherwise the build system might not do exactly what you want. e.g. if you do:

make extension=d_fat
make install

then the 1st line will build the fat binaries (with the "d_fat" extension); but the 2nd line will try to install the normal binaries (with the "pd_darwin" extension), which it won't find. because "make" is good at resolving dependencies it will then compile again to produce (non-fat) .pd_darwin files and install them.

Now I should just delete the first "Darwin-amd64-32/pd_darwin" from deken, > right?

since you asked: i think people have told you multiple times that you should not remove things from deken. in the general case, there is little to no benefit, but the potential of a lot of harm.

I just want to be clear there's no reason to keep it. If my previous package is better in any way or something (like "faster"?).

the package is smaller.

I assume it would show both options for download and people will just be confused if there's no reason to pick one over the other.

if both packages have the same version number and run on your architecture, they will both show. but people will basically get the same thing, regardless whether they click on one or the other. so there's no harm in the confusion (in the end).

if you want to avoid confusion totally (because you are friendly and don't want to impose *any* mental stress onto people), upload a new version.

in general i think you should consider the deken storage as immutable ("don't even think of trying to modify and/or delete stuff once published"). i would love to enforce this on the server-side, but it's very low on my TODO list.

gmadsr IOhannes

Ideally, I'd also have to repack and reupload earlier 0.5-x versions, as I did it wrong and didn't upload the linux capital letter aliases... how would that go if it's immutable? Seems too extreme for me and there could be good reasons to reupload a package at least when they screw up. And what if you have a typo?

If you want to fix an existing older version (= backporting), you would usually do a new bugfix release for that version. For example, to fix 0.4.10, you would make a bugfix 0.4.11.

That being said, often it's sufficient to just fix the latest version and ask people to upgrade. Backporting only makes sense if you need/want to support existing, possibly incompatible versions of programs/libraries, where upgrades are non-trivial. A good example are operating systems.

Christof

On 20.10.2020 22:36, Alexandre Torres Porres wrote:

Em ter., 20 de out. de 2020 às 03:34, IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> escreveu:

> Tried in the makefile and it didn't work, but then I thought you
may have
> meant when doing "make install" and it worked ;)

i don't know what you tested.
but you should pass the "extension=..." argument to all

invocations of make

I did *make install objectsdir=../ extension=d_fat *and pd-lib-builder generated binaries with that extension.

> I just want to be clear there's no reason to keep it. If my previous
> package is better in any way or something (like "faster"?).

the package is smaller.

I see! Not enough a good reason for me to also compile it that way though...

if you want to avoid confusion totally (because you are friendly and
don't want to impose *any* mental stress onto people), upload a
new version.

I get it. Well, I'm talking about cyclone, which I made a release on the 17th and on the 19th I had the other binary... that's too soon and too little for a new release. And yeah, I do think it's an unnecessary confusion/stress, not everyone knows the difference and might not know what to pick.

in general i think you should consider the deken storage as immutable 

("don't even think of trying to modify and/or delete stuff once
published"). 

i would love to enforce this on the server-side, but it's very low
on my 

Still about cyclone, I just released 0.5-4! Ideally, I'd also have to repack and reupload earlier 0.5-x versions, as I did it wrong and didn't upload the linux capital letter aliases... how would that go if it's immutable? Seems too extreme for me and there could be good reasons to reupload a package at least when they screw up. And what if you have a typo?

Anyway, I'm too busy and lazy to repack and reupload cyclone anyway.

cheers

---

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