On Oct 6, 2016, at 9:56 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > I wouldn't hard-fail, but completely disable objc-gc with an appropriate > warning. The Objective-C maintainers may have other preferences, though.
gcc historically is fairly weak at complex configurations. I need the 32 bit libraries to support -m32, but, those libraries might not be present, but do I build all the rest of my libraries, and if i do, do I test them once build, but what is other dependent external libraries are missing. Do I turn off the multilib, or do I not? I used to manage some of this by passing in configure flags to control multilibbing based upon what libraries were install and then run testing based upon that. Of course, that's all external to gcc proper. Doesn't really make gcc any easier to configure and build or advance gcc. We could smell the system at configure time, and turn on and off multilib variants and things like objc gc. Target specific, but I think it helps to ponder this in a target independent way. This can then turn on and off objc gc support directly. To get it on, one would need to install the needed libraries, and reconfigure and rebuild gcc. I think I might like that the best. Has a nice easy of use about it, and then everything gcc does is rather sane (no funny build errors when a needed library isn't present). So, I think, if I understand what you propose, I'm fine with that.
