On 4/2/2010 6:11 PM, Eduardo Poyart wrote: > In OSX 10.6, gcc defaults to x86_64. That is, if you don't use any arch > flags it will compile for x86_64. in OSX 10.5, the default is i386. > If we by default don't use any arch flags in CS, it will compile in the > system's default mode, which I think is a good thing. That's what I propose. > Users should be able to do "./configure; make; make install" on external > libraries like zlib, and "./configure; make; make install" on CS, and it > should work. > If we force our default to be i386, and zlib is compiled with its > default parameters, it will break on OSX 10.6.
This is why I suggested possibly changing the default to --disable-universal-binary rather than --enable-universal-binary. When universal binary is disabled, the CS build does not explicitly specify any architecture, which means that the build tools will use whatever is their built-in default, hence "./configure; make; make install" is most likely to "just work" for most development needs. Another argument for disabling universal binary by default is that the bulk of development work probably can be done (and compile faster) without worrying about multiple architectures. Universal binary builds, on the other hand, are needed less frequently: typically when explicitly testing on other architectures, and when making builds for release. The primary reasons I chose ultimately to have universal binary enabled by default when implementing the support were: (1) it side-steps the problem of developers having to be told explicitly how to build their projects to support multiple architectures, and (2) it forces developers at least to be aware of the issue, requiring them to take some action: either disabling universal binary or setting up their development environment properly to support it. Having universal binary enabled by default causes a bit more developer headache at project start, whereas having it disabled results in more headache part way into the project or toward the end. I can see benefits in either choice. -- ES ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Crystal-main mailing list Crystal-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:crystal-main-requ...@lists.sourceforge.net?subject=unsubscribe
