Thanks. Do you think there is a case for a new recipe class setting these env vars for python recipes that need them (like CythonRecipe but for things other than cython)? If these things are general enough, it would make it easier to support e.g. multiple python versions.

I agree that there is a lot of similarity between the Apsw, M2Crypto and pyLevelDB recipes setting the python linker and including the headers. Why is this not needed by every python recipe is what I am wondering?
This part seems to be a bug btw, because without it the setup.py uses the default gcc for linking whereas the compilation step does use the right gcc for the architecture:

# Set linker to use the correct gcc
env['LDSHARED'] = env['CC'] 

Also these settings are recurring for all libraries that want to use the regular gnu c stl:

env['CFLAGS'] += ' -I' + self.ctx.ndk_dir + '/platforms/android-' + str(self.ctx.android_api) + '/arch-' + arch.arch.replace('eabi', '') + '/usr/include' + \
                 ' -I' + self.ctx.ndk_dir + '/sources/cxx-stl/gnu-libstdc++/' + self.ctx.toolchain_version + '/include' + \
                 ' -I' + self.ctx.ndk_dir + '/sources/cxx-stl/gnu-libstdc++/' + self.ctx.toolchain_version + '/libs/' + arch.arch + '/include'
env['CXXFLAGS'] = env['CFLAGS']
env['CXXFLAGS'] += ' -frtti'
env['CXXFLAGS'] += ' -fexceptions'
env['LDFLAGS'] += ' -L' + self.ctx.ndk_dir + '/sources/cxx-stl/gnu-libstdc++/' + self.ctx.toolchain_version + '/libs/' + arch.arch + \
                  ' -lgnustl_shared'

Perhaps a special recipe class could be made for that as well?

This is not necessary in every python recipe because they don't normally
do any compilation. This is by design - PythonRecipe is intended for pure python things. I think the reason I didn't just add the compilation flags to PythonRecipe was so that it would be explicit when compiling recipes were used, especially when different types were chosen.

Actually, there's already a recipe for pythonrecipes with compiled
components. Maybe you can use that one, though I don't remember exactly
what conditions it targets. I'll take a look at this next time I have time.

On 04/03/16 21:07, Paul Brussee wrote:

I agree that there is a lot of similarity between the M2Crypto and
pyLevelDB recipes setting the python linker and including the headers.
Why is this not needed by /every/ python recipe is what I am wondering?
This part seems to be a bug btw, because without it the setup.py uses
the default gcc for linking whereas the compilation step /does/ use the
right gcc for the architecture.

|# Set linker to use the correct gcc env['LDSHARED'] = env['CC'] |

Also these settings are recurring for all libraries that want to use the
regular gnu c stl:

|env['CFLAGS'] += ' -I' + self.ctx.ndk_dir + '/platforms/android-' +
str(self.ctx.android_api) + '/arch-' + arch.arch.replace('eabi', '') +
'/usr/include' + \ ' -I' + self.ctx.ndk_dir +
'/sources/cxx-stl/gnu-libstdc++/' + self.ctx.toolchain_version +
'/include' + \ ' -I' + self.ctx.ndk_dir +
'/sources/cxx-stl/gnu-libstdc++/' + self.ctx.toolchain_version +
'/libs/' + arch.arch + '/include' env['CXXFLAGS'] = env['CFLAGS']
env['CXXFLAGS'] += ' -frtti' env['CXXFLAGS'] += ' -fexceptions'
env['LDFLAGS'] += ' -L' + self.ctx.ndk_dir +
'/sources/cxx-stl/gnu-libstdc++/' + self.ctx.toolchain_version +
'/libs/' + arch.arch + \ ' -lgnustl_shared' |

Perhaps a special recipe class could be made for that as well?

—
Reply to this email directly or view it on GitHub
#652 (comment).

For the LDSHARED thing, where is that line of code? Right now it should use liblink.sh, or with crystax does use env['CC'] + '-shared', but this seems to work (maybe the gcc arch doesn't matter for the linking?). I don't know much about linking though, and could easily have missed something.

It is on line 36 of this recipe.

I tried refactoring it into a CompiledComponentsPythonRecipe but if I use the setup_extra_args it gives them not only tot the build call of setup.py but also to the install setup.py call and that is not what I want because that takes different arguments.