Working on issue 23496: should I use a macro test or an edit to configure.ac?
So... There was a recent discussion here on porting Python to Android. Well, for those of you who saw too many unread messages and marked the whole thread as read like I usually do, I helped Cyd figure out some patches that make it work. Cyd then opened Issue 23496 <http://bugs.python.org/issue23496>. Now, I'm going to try to redo the patches against HEAD (or tip in Mercurial language). Which leads me to the question. See, of course, the patches should only be enabled if Python is being built targeting Android, but I'm not sure how that should be detected. I know that the Android target triple is arm-linux-androideabi. Should I test for the __ANDROID__ macro in the source file, or should I modify configure.ac to detect Android and define its own macro? Also, if a configure.ac edit is preferred, where should it be? It's slightly painful to scan through all 4000 lines of Python's configure script. ;) -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
DOES NOBODY HAVE AN ANSWER TO THIS??? I'm REALLY relying on someone who works on Python to answer this. PLEASE?? On Wed, Feb 25, 2015 at 12:17 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
So...
There was a recent discussion here on porting Python to Android. Well, for those of you who saw too many unread messages and marked the whole thread as read like I usually do, I helped Cyd figure out some patches that make it work. Cyd then opened Issue 23496 <http://bugs.python.org/issue23496>. Now, I'm going to try to redo the patches against HEAD (or tip in Mercurial language).
Which leads me to the question. See, of course, the patches should only be enabled if Python is being built targeting Android, but I'm not sure how that should be detected.
I know that the Android target triple is arm-linux-androideabi. Should I test for the __ANDROID__ macro in the source file, or should I modify configure.ac to detect Android and define its own macro? Also, if a configure.ac edit is preferred, where should it be? It's slightly painful to scan through all 4000 lines of Python's configure script. ;)
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
I'm not an official cpython developer but ifdef __ANDROID__ is quite in line with other per-platform support (__FreeBSD__, __linux__, etc), as well as already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ not being defined when it should be? On Thu, Feb 26, 2015 at 4:20 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
DOES NOBODY HAVE AN ANSWER TO THIS???
I'm REALLY relying on someone who works on Python to answer this. PLEASE??
On Wed, Feb 25, 2015 at 12:17 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
So...
There was a recent discussion here on porting Python to Android. Well, for those of you who saw too many unread messages and marked the whole thread as read like I usually do, I helped Cyd figure out some patches that make it work. Cyd then opened Issue 23496 <http://bugs.python.org/issue23496>. Now, I'm going to try to redo the patches against HEAD (or tip in Mercurial language).
Which leads me to the question. See, of course, the patches should only be enabled if Python is being built targeting Android, but I'm not sure how that should be detected.
I know that the Android target triple is arm-linux-androideabi. Should I test for the __ANDROID__ macro in the source file, or should I modify configure.ac to detect Android and define its own macro? Also, if a configure.ac edit is preferred, where should it be? It's slightly painful to scan through all 4000 lines of Python's configure script. ;)
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rmsr%40lab.net
On 02/26/2015 05:13 PM, Ryan Smith-Roberts wrote:
I'm not an official cpython developer but ifdef __ANDROID__ is quite in line with other per-platform support (__FreeBSD__, __linux__, etc), as well as already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ not being defined when it should be?
I believe the issue is adding in Android support, and how best to do it. -- ~Ethan~
On Thu, Feb 26, 2015 at 5:13 PM, Ryan Smith-Roberts <rmsr@lab.net> wrote:
I'm not an official cpython developer but ifdef __ANDROID__ is quite in line with other per-platform support (__FreeBSD__, __linux__, etc), as well as already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ not being defined when it should be?
Might as well spend the time to answer my own question: Some Googling indicates that __ANDROID__ is baked into the NDK toolchain, so it's definitely what one would use to wrap Android-specific code. "__ANDROID__ shall always be defined by the toolchain, without a need for special flags though, so please rely on that instead in your code." - David Turner, Android NDK Lead, 2010.
Thank you so much! Ryan Smith-Roberts <rmsr@lab.net> wrote:
On Thu, Feb 26, 2015 at 5:13 PM, Ryan Smith-Roberts <rmsr@lab.net> wrote:
I'm not an official cpython developer but ifdef __ANDROID__ is quite in line with other per-platform support (__FreeBSD__, __linux__, etc), as well as already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ not being defined when it should be?
Might as well spend the time to answer my own question:
Some Googling indicates that __ANDROID__ is baked into the NDK toolchain, so it's definitely what one would use to wrap Android-specific code.
"__ANDROID__ shall always be defined by the toolchain, without a need for special flags though, so please rely on that instead in your code." - David Turner, Android NDK Lead, 2010. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Check out my website: http://kirbyfan64.github.io/
On 02/25/2015 10:17 AM, Ryan Gonzalez wrote:
Which leads me to the question. See, of course, the patches should only be enabled if Python is being built targeting Android, but I'm not sure how that should be detected.
I know that the Android target triple is arm-linux-androideabi. Should I test for the __ANDROID__ macro in the source file, or should I modify configure.ac <http://configure.ac> to detect Android and define its own macro? Also, if a configure.ac <http://configure.ac> edit is preferred, where should it be? It's slightly painful to scan through all 4000 lines of Python's configure script. ;)
Anybody have any words of wisdom on this? -- ~Ethan~
participants (4)
-
Ethan Furman -
Ryan -
Ryan Gonzalez
-
Ryan Smith-Roberts