Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[mark b. <mbr...@ai...>]

On Jan 9, 2012, at 6:49 AM, Arthur Norman wrote:

> On Sun, 8 Jan 2012, mark brethen wrote:
>> An update to my previous post:
>> 
>> Macports handles the configure and build phases; all that needs to be 
> passed are the arguments, it handles all the environment variables. One 
> drawback is that I can't pass both --with-csl and --with-psl. So I had to 
> override macports' configure phase. At first, I used:
>> 
>> configure {
>> system -W ${worksrcpath} "./configure --prefix=${prefix} --with-csl ; ./configure --with-psl"
>> }
>> 
> 
> As regards this I might note that the CSL and PSL variants of Reduce are 
> for almost all purposes ALTERNATIVES rather than being things where 
> installing one should automatically install the other. I guess there are 
> three sorts of people in the world:
> (1) Developers who are not just keen on getting their Reduce package in 
> good condition, but who wish to be properly careful that the code involved 
> is compatible with both the CSL and the PSL-supported variants. Of all the 
> people who download and install Reduce I believe these count as a tiny 
> minority.
> (2) General users. They only need EITHER the PSL or the CSL based version 
> of Reduce. Installing both just clutters up their disc space, makes the 
> installation process slower and in general causes confusion! There is of 
> course a potential uncertainty as to which to choose, but even if theyu 
> install both to start with after a while tidiness will cause them to 
> de-install the one that does not suit them.
> (3) Extreme users. Some (but ony a VERY FEW) users will be trying 
> calculations so large that they fail on one or other version. Or they may 
> trigger a bug in one or other version, or performance may differ enough to 
> be critical. These people may want both versions installed so thay can 
> switch between them as thay hit issues. Again I believe these are a tiny 
> (but obviosuly important) minority.
> 
> So I might have expected that one Macport package for the CSL and one for 
> the PSL version would be more use for customers as well as less strain for 
> you.
> 
I've already had a lengthy discussion on the macports-dev list about subports, variants, 
or everything in one port. subports is probably the way to go, if it was desired to have 
separately installable ports and avoid duplicate scripting. The only disadvantage is the 
svn source, which is around 370MB, which would have to be checked out from the 
project's repository each time. Macports currently archives only tarball dists, but there
is an open ticket to resolve this. 

> 
> Your extract showing "errors" is in fact not terribly helpful to me even 
> if I wanted to check it! It does not provide context. Is this an extract 
> from a config.log? You will be aware that configure does all sorts of 
> things that cause "errors" in that when it is checking for the 
> availability of something it tries using it, and if the attempt does or 
> does not succeed it sets its various flags. So from what you send I can 
> not tell if the messages you send are merely the normal process of 
> configuration when it checks to see if llvm-gcc-4.2 is installed as one of 
> the possible compilers of interest, or of it is an Error with a capital 
> letter. In general when configure is run and something fails one looks in 
> config.log and can see the exact command that was invoked and the contents 
> of the file that was being presented for compilation. It is lengthy and 
> messy and you need (as I say) to distinguish between compilations that 
> fail merely incidentally because they are checking for some (optional) 
> feature that is not present on the machine concerned, and errors that are 
> indications of true disaster.
> 
I've attached the config.log from the fox directory for your perusal.