4 ms·

> ./configure scripts generated by GNU autoconf determines whether a linker supports modern GNU-compatible features or not by searching for "GNU" in the --help

by rui314 9y ago

> ./configure scripts generated by GNU autoconf determines whether a linker supports modern GNU-compatible features or not by searching for "GNU" in the --help message. To be compatible with the scripts, we decided to add a string "(compatible with GNU linkers)" to our --help message. This is a hack, but just like the web browser's User-Agent string (which everyone still claim they are "Mozilla/5.0"), we had no choice other than doing this to claim that we accept GNU-compatible options. http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.html http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.h... Even though I wrote it, I found this part a bit funny. Configure scripts are hacky by their nature, and we needed another hack to make their hack work. I'm not happy about that though.

chubot 9y ago
Yup, this is why feature detection is better than version detection. jQuery changed their strategy in 2009: http://blog.jquery.com/2009/01/14/jquery-1-3-released/ http://blog.jquery.com/2009/01/14/jquery-1-3-released/ "No More Browser Sniffing" Also, autoconf has a lot of faults, but as far as I recall it's firmly based on the philosophy of feature detectino vs. version detection. Maintainers of packages can write bad custom checks that test for features, but if you use the built-in autoconf checks, they're all about features. CMake on the other hand seems to use version detection more, which I don't like.
- wvenable 9y ago
  It helps when you have a platform that supports feature detection reliably. Most platforms don't have that lucky accident.
  - chubot 9y ago
    What's an example where of a feature of cc or ld that you can't detect with feature detection? Shell scripts are turing complete and can do arbitrary I/O. In theory you can write a feature detection for any feature by compiling, linking, and running a test program. If the feature couldn't be detected this way, then it would be useless. Likewise, JavaScript and DOM features should always be detectable by eval(). I guess one instance where it's impossible is if the API changes the pixels on the screen and does nothing else. Although you can actually detect this in some cases with JavaScript! JavaScript can leak information through the colors of attributes on the screen, e.g. you can tell if a user visited a site by looking if the link is purple!
    - derefr 9y ago
      > In theory you can write a feature detection for any feature by compiling, linking, and running a test program. If the feature couldn't be detected this way, then it would be useless. It's hard to do feature-detection against cross-compilation toolchains, since "toolchain" doesn't imply a standardized emulator/debugger component for the resulting executables. Under cross-compilation, you can detect that your test programs compile and link, but you can't run them! This, if you're wondering, is why SDKs for embedded architectures always seem stuck in the time before autoconf/cmake were invented: without feature-detection support, such toolchains (and the projects developed for them) have to get by with manually-written Makefiles. This is also why the more modern game console SDKs (such as the Wii U SDK, my own most recent experience) are delivered as components that slide into an IDE like Visual Studio, rather than as standalone CLI toolchains for an IDE to drive. This way, they do have a (proprietary) standard way to add an emulator/debugger component, which can then serve as a core for the IDE's build system.
      - chubot 9y ago
        Yes good point. Though I think most features can be tested without running a program -- e.g. testing if a library function exists or has a certain signature. I think embedded toolchains use plain makefiles because they tend to fork code rather than upstream changes. And that is due to the ship-it-and-forget-it mindset of embedded companies that is well known among open source maintainers.
    - 0x0 9y ago
      No modern browser lets you know the state of a:visited and will lie to you if you query for colors etc. In fact if you can find a way for js to determine if a link has been visited you are likely qualified for $$$ bug rewards (which has happened)
      - vosper 9y ago
        That's not really feature detection, though.
      - chubot 9y ago
- chrisweekly 9y ago
  Good comment, triggers a bunch of associations: 1. the rule of thumb to prefer feature detection to user-agent sniffing is generally a reasonable one, BUT if you have something like WURFL to map UA to device (and device to capabilities) then the one-time, up-front lookup can be a better choice. 2. that said I remember using yepnope.js, and sharing this hilarious (because accurate) post on the history of the user-agent: http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/ hard to believe it's been almost 20 years since I started messing with HTML...
- ComputerGuru 9y ago
  Which is why jQuery throws (and handles) exceptions every single time I run it under a debugger. Ugh.

by rui314 9y ago

chubot 9y ago

Yup, this is why feature detection is better than version detection. jQuery changed their strategy in 2009: http://blog.jquery.com/2009/01/14/jquery-1-3-released/ http://blog.jquery.com/2009/01/14/jquery-1-3-released/ "No More Browser Sniffing" Also, autoconf has a lot of faults, but as far as I recall it's firmly based on the philosophy of feature detectino vs. version detection. Maintainers of packages can write bad custom checks that test for features, but if you use the built-in autoconf checks, they're all about features. CMake on the other hand seems to use version detection more, which I don't like.

wvenable 9y ago
It helps when you have a platform that supports feature detection reliably. Most platforms don't have that lucky accident.
- chubot 9y ago
  What's an example where of a feature of cc or ld that you can't detect with feature detection? Shell scripts are turing complete and can do arbitrary I/O. In theory you can write a feature detection for any feature by compiling, linking, and running a test program. If the feature couldn't be detected this way, then it would be useless. Likewise, JavaScript and DOM features should always be detectable by eval(). I guess one instance where it's impossible is if the API changes the pixels on the screen and does nothing else. Although you can actually detect this in some cases with JavaScript! JavaScript can leak information through the colors of attributes on the screen, e.g. you can tell if a user visited a site by looking if the link is purple!
  - derefr 9y ago
    > In theory you can write a feature detection for any feature by compiling, linking, and running a test program. If the feature couldn't be detected this way, then it would be useless. It's hard to do feature-detection against cross-compilation toolchains, since "toolchain" doesn't imply a standardized emulator/debugger component for the resulting executables. Under cross-compilation, you can detect that your test programs compile and link, but you can't run them! This, if you're wondering, is why SDKs for embedded architectures always seem stuck in the time before autoconf/cmake were invented: without feature-detection support, such toolchains (and the projects developed for them) have to get by with manually-written Makefiles. This is also why the more modern game console SDKs (such as the Wii U SDK, my own most recent experience) are delivered as components that slide into an IDE like Visual Studio, rather than as standalone CLI toolchains for an IDE to drive. This way, they do have a (proprietary) standard way to add an emulator/debugger component, which can then serve as a core for the IDE's build system.
    - chubot 9y ago
      Yes good point. Though I think most features can be tested without running a program -- e.g. testing if a library function exists or has a certain signature. I think embedded toolchains use plain makefiles because they tend to fork code rather than upstream changes. And that is due to the ship-it-and-forget-it mindset of embedded companies that is well known among open source maintainers.
  - 0x0 9y ago
    No modern browser lets you know the state of a:visited and will lie to you if you query for colors etc. In fact if you can find a way for js to determine if a link has been visited you are likely qualified for $$$ bug rewards (which has happened)
    - vosper 9y ago
      That's not really feature detection, though.
    - chubot 9y ago
chrisweekly 9y ago
Good comment, triggers a bunch of associations: 1. the rule of thumb to prefer feature detection to user-agent sniffing is generally a reasonable one, BUT if you have something like WURFL to map UA to device (and device to capabilities) then the one-time, up-front lookup can be a better choice. 2. that said I remember using yepnope.js, and sharing this hilarious (because accurate) post on the history of the user-agent: http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/ hard to believe it's been almost 20 years since I started messing with HTML...
ComputerGuru 9y ago
Which is why jQuery throws (and handles) exceptions every single time I run it under a debugger. Ugh.