Cameron> Clearly. I want to take this opportunity, though, to Cameron> understand attitude-intent-design, so that any patches in which Cameron> I'm involved will not merely imitate what (perhaps mistakenly) Cameron> exists, but will promote long-term usability and Cameron> maintainability. Cameron, We're talking about configure and you're talking about usability and maintainability. What rock have you been hiding under? <wink> On a more serious note, if there is a way to break up configure.in into separate scripts (I don't care if configure is generated as a single script) I'd be happy to take a stab at it. That would make it easier for potential editors to restrict their damage^H^H^H^H^H^Henhancements to a smaller chunk of the overall configure script. If I can get a list of options currently generated for the HP compiler (not GCC, right?) and what would produce a processor-independent executable, I'll take a crack at tweaking configure.in and adding a --native-hpux flag or something similar. I think the basic problem here is that while many compilers can generate processor-dependent code, the default is usually to create processor-independent code. It appears HP flipped the switch on that, so we have to do a little more work to ensure processor independence. Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4