Henry, Thanks for the good input! Replies inline.
> - --with-toolchain-type=list shows up after quite a few configure going on > already, we probably want to have this done in an earlier stage. I'd like that too. Unfortunately, given the autoconf framework, that's impossible, and would require us to rework a huge piece of code. It's just not worth it. :-( If it looks too ugly, maybe I should rethink the whole "list" idea. Ideally, this information should be in the help instead. There's not just any good ways to get it there. But there might be a few bad, or at least ugly. :) I'll see if I can do something along those lines. > - The "available" toolchains feels to me should be available on the build > system, i.e., they are installed and available to use. From what is > implemented, it's more "valid choices" than "available". You are correct. Perhaps an unfortunate choice of word. I'll replace with "valid". > - On the above note, should "list" list "available" or "valid choices"? Listing actually available is hard and probably not necessary. It requires us to go through the complete check for the compilers etc. > - Do we want to allow convention name cc and CC and detect what it is or > simply ask for explicit choice as it is imeplemted now? Although I don't > think it's likely for a system to install, say gcc, as cc instead of create a > symbolic link alias for gcc, I cannot be sure. I didn't say so in my previous mail, but one follow-up functionality I'm planning to implement is to set compiler using CC or CXX. In this case, we'll try to detect toolchain type automatically. But unless we specify CC explicitly like that, I believe the best way is to default to a toolchain and try to detect it using conventional names, e.g. bcc. > - I understand clang is not a goal for this patch. From experience, it's > almost work like gcc. Does it make sense to have gcc flags as a fallback? > This bring up the question before, should we have a fallback default to > unknown toolchain? Even if we check for supported toolchain, all such setting > should probably still be defensive with gcc as default. Otherwise, I can > configure with clang but quite a few setting would be missing. I do not like the idea of a fallback like that. If we cannot detect the compiler, then things are likely to go wrong. And one core value in the configure thinking is that if it should fail, it should fail early, in the configure step, not in make. The one reason I can see for not enforcing us to detect compiler correctly is if you're adding support for a new compiler, like clang, and have not bothered to write the new detection code yet. In that case, you'll just have to comment out the check. > - On windows, gcc is listed as an available toolchain, I think this is good. > However, we still do TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV if select gcc as > toolchain. That should not be checked for gcc? You have a point. :) On the other hand, we cannot currently build with gcc on Windows. So, actually, I should remove the non-tested combinations of toolchain and platform. It looked nice adding them, and the potential for implementing them is there, but it looks like something should work that will not. If we implement gcc support for Windows, or solstudio support for linux, etc, we'll just add them back. (That's going to be the easy part :)) /Magnus
