Charles R Harris wrote: > > The declarations were for the SPARC. Originally I had them up in an > ifdef up top, but I got curious what different machines would do.
I still don't understand what exact problem they solve. Since the declarations are put when HAVE_FOO is defined, the only problems I can see are problem in the detection code or a platform bug (I seem to remember for SPARC, this was a platform error, right ?). In either case, it should be solved elsewhere (at worst, for platform specific, this should be done within #if PLATFORM/#endif). > They shouldn't cause a problem unless something is pretty strange. They do; the default rule should be not to put any external declaration, because they are heavily toolchain/platform specific. I removed a lot of them from the old code when I refactored this code, and putting them back almost totally alleviate my effort :) To quote python code itself (pyport.h): /************************************************************************** Prototypes that are missing from the standard include files on some systems (and possibly only some versions of such systems.) Please be conservative with adding new ones, document them and enclose them in platform-specific #ifdefs. **************************************************************************/ > The undefs I put where they are for similar reasons, but there was a > strong temptation to move them into the if statement where they used > to be. Could you be more specific ? I want to know the actual error they were solving. > Let's say curiousity got the best of me there. They shouldn't affect > anything but macros and I didn't want the function declarations do be > interpreted as macros. "Shouldn't affect" is not good enough :) The default rule should be to avoid relying at all on those distinctions, and only care when they matter. Doing the other way around does not work, there alway be some strange platform which will break most assumptions, as rationale as they can be. > > Worth knowing ;) It works on the windows buildbot but that is running > python 2.4. Ah, it is 2.4 ! I was wondering the exact combination. It does not work with the platform SDK 6.1 (which includes 64 bits compiler), and this results in a compiler segfault. The problem is particularly pernicious, since the segfaults is not seen directly, but put in a temp file which itself causes problem because two processes try to access it... One of the nicest build failure I have ever seen :) > Speaking of which, the BSD buildbot needs nose (I don't know what > happened to it), the windows box is showing the same old permissions > problem, and one of the SPARC buildbots just times out unless you > build during the right time of day. We are just hobbling along at the > moment. Windows problems at least are not specific to the buildbot. > > Sorry for the late reply, the network was down. No problem, David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
