[PD-dev] [ pure-data-Patches-3521816 ] Setting externals file extension, check for ANDROID platform

SourceForge.net noreply at sourceforge.net
Mon Apr 30 09:28:09 CEST 2012


Patches item #3521816, was opened at 2012-04-26 19:25
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&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: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting externals file extension, check for ANDROID platform

Initial Comment:
The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it.

Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work.

It doesn't address the issue of Android x86.

Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros.


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

>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-30 00:28

Message:
for the record, here are the relevant threads i found in the archives:
- http://lists.puredata.info/pipermail/pd-list/2009-01/067498.html
- http://lists.puredata.info/pipermail/pd-list/2009-07/071476.html

as you will see, the only real issue that was ever raised was the increased
load-time when adding more and more extensions. all the "other" issues
where always referred to as "there are other issues which i don't remember
right now, check the archive", without ever giving evidence that there are
indeed other issues.

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

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 20:14

Message:
File extensions are very OS-specific.  The Linux extensions are fine
(except perhaps the l_ia64 being the wrong arch).  Mac OS X does not need
different ones since you can build universal "fat" binaries.

One example of a problem caused by adding more extensions is that it
increases the load time since Pd will have to check for more variations on
filenames.  There are other issues, I don't remember them, but they're in
the archives.

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

Comment By: Miller Puckette (millerpuckette)
Date: 2012-04-29 11:03

Message:
My intention in having the wierd extensions was to permit people to
distribute patches (such as realizations
of pieces) containing in-house externals that can run under any Pd version
and any OS.  In this context
"externs" can be directories containing the various binaries which Pd
distinguishes by filename.  OTOH, Pd
distributions themselves run on a single OS and architecture so don't need
the disambiguation, although in
my experience it hasn't been harmful (Hans has experienced otherwise in the
context of Pd extended though :)
So Pd is sort of stuck allowing both types of extensions.

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

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 10:36

Message:
Personally, I think its a waste your time and mine.  Its been discussed,
check out the archives for the problems it causes.  I've long since moved
on.  We should be putting this energy solving the issue in this tracker,
rather than beating the .d_ppc/.d_fat dead horse.


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

Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-28 10:16

Message:
thanks for the respone.

ad #1: very few people using .d_ppc/.d_fat is not really creating any
"problems", is it?

ad #2: will do (though afaict, PdX has a patch that actively removes the
functionality; should i create a patch that re-adds the extensions or
should i modify (eventually remove) the patch that erroneously removes the
extensions?

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

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 19:32

Message:
In response to #1: very few people are using .d_ppc and .d_fat files with
Pd vanilla.

and #2: patches welcome

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

Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-27 08:54

Message:
<flames>
"Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extension"...what
exactly is the "lot of issues" here? no other program for Darwin/MacOSX is
called "Pd", and still this is no issue.
</flames>
<moreflames>
if Pd-extended ignores binary files that it could happily load and by doing
so breaks compatibility with Pd-vanilla, i would say this is a bug in
Pd-extended.
</moreflames>

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

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 07:36

Message:
What about just defining '.so' has a possibility if __linux__, __FreeBSD__,
__FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to
manage the architecture in their own way.

Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extensions: they use
universal binaries.  For this reason , Pd-extended on Mac OS X only uses
.pd_darwin and universal binaries and ignores .d_fat and .d_ppc.  Also,
Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so
that file extension is just wrong.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_id=55736



More information about the Pd-dev mailing list