On 2014-2-16 06:38 , Rainer Müller wrote: > On 2014-02-14 15:43, Hiroshi Umemoto wrote: >> >>> This isn't a change to swig but to the binding subports. What >>> arch-specific files do you see them installing? >> >> As you pointed out, the subports seem to install no arch-specific files at >> all. However, if you try to install one of the swig subports from source, a >> standard compilation process for the swig executable will begin. In my case, >> I failed to install the i386 version of swig-python on Lion OS. > > The 'supported_archs noarch' only refers to the files being installed. > The implication when using this line is that the produced binary archive > can be installed on any arch. The build process is still allowed need to > execute commands to generate output files. > >>From a quick look at the files installed by swig-python, the noarch > label was correct.
I think he means swig was failing to compile because it was compiling with no archflags and thus defaulted to x86_64, but the dependencies were i386. This can happen because the binding subports actually do a full build of swig and then throw away everything but the files for the desired binding, which are noarch. So this is a kind of unusual situation in which the build fails because part of it, which will be thrown away at the end, is not noarch. I'm not sure how much of a build process is needed for the binding files or if we could bypass building the other stuff (which would be a win for build times too). - Josh _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
