Opened at 2010-11-16T06:56:23Z
#64 new defect
prevent with-embedded-cryptopp builds from using object files from without-embedded-cryptopp builds or vice versa
Reported by: | zooko | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Version: | 0.5.19 | Keywords: | |
Cc: | Launchpad Bug: |
Description
<zooko> if you run python setup.py build it builds a bunch of C++ files with certain #include's and then links them with -lsomelib. <zooko> If you run python setup.py build --disable-embedded-cryptopp then it builds them with different #includes and links them to a different -lsomelib. <zooko> Unfortunately, if there are still .o files from an earlier build that had a different setting for that flag then those .o's were build with the wrong #includes. [23:16] <zooko> If I were using make, I would tell make that the .o files depended on the --disable-embedded-cryptopp flag somehow. <zooko> Actually I'm not sure how I would do that in make, either. <merwok> Hm, reminds me of an infixable bug in distutils [23:17] <zooko> If I could tell it that the name of the temporary "build" dir where it should look for .o files has to be different depending on the setting of the --disable-embedded-cryptopp flag, that would solve it. <merwok> zooko, you can, in a build_ext subclass <zooko> merwok: aha, that sounds promising. <merwok> zooko: Otherwise you may hit http://bugs.python.org/issue10374 [23:18] <zooko> merwork: if I have a build_ext subclass, <zooko> how do I change the name of the dir in which it looks for .o's? [23:19] <merwok> Looks like a default value for build_dir (or build_base, or build_temp) in finalize_options <merwok> Of course, they can be built in place too, you may want to reject that option.
Note: See
TracTickets for help on using
tickets.