5 ms·

The zlib code has to make numerous workarounds for old compilers that do not understand ANSI-C or to accommodate systems with limitations such as operating in a

The zlib code has to make numerous workarounds for old compilers that do not understand ANSI-C or to accommodate systems with limitations such as operating in a 16-bit environment. This is true for many older open source libraries. I wonder: - Are old platforms still tested as time passes? Is it really worth it maintaining extra cruft for old systems even if it is unknown whether it still works? Are there projects running CI for OS/2 Warp, MS-DOS, or A/UX? - How many users of old or obscure platforms are there still around? Are they even updating such libraries? - What platforms do we need to get rid of to get rid of autoconf/automake/configure and use e.g. CMake instead?

kukkukb 11y ago
Wasn't this one of main reasons that thenNeoVim project was started?
stefantalpalaru 11y ago
> What platforms do we need to get rid of to get rid of autoconf/automake/configure and use e.g. CMake instead? Why would you want that? Autotools is the devil we know. CMake has its own problems and from a statistical sample of one project implementing both, I came to the conclusion that CMake is more frustrating than Autotools when you need to do something unusual.
- tanderson92 11y ago
  Exactly. autotools is exceptionally well designed for dealing with more exotic use cases like cross compiling. When designing a cross-compiling linux distribution(http://exherbo.org/docs/multiarch.txt http://exherbo.org/docs/multiarch.txt) we discovered that autotools is by far the easiest to deal with when it comes to arbitrary host & build targets, compilers, etc. I would be even bolder and say that: Those who do not understand autotools are doomed to reinvent it, poorly.
  - danieldk 11y ago
    Exactly. autotools is exceptionally well designed for dealing with more exotic use cases like cross compiling. ...and it cannot deal with non-exotic use cases like non-UNIX environments (think Windows + Visual Studio) well at all. In contrast, with CMake you can generate an nmake file or Visual Studio project with one command.
    - JoshTriplett 11y ago
      On the other hand, with autotools you can cross-compile for Windows using MinGW.
      - Sanddancer 11y ago
        Just like someone under unix could always just use mono's xbuild to build a project using visual studio's .vsproj files. Course, people tend to get grumpy when you tell them that they have to jump through hoops to use your project, just like your suggestion...
  - nitrogen 11y ago
    I use CMake to cross-compile firmware for my home automation hardware. It doesn't seem too bad, just a single file shared across all projects that defines the compiler binaries and settings. I like it much better than autotools.
    - detaro 11y ago
      Do you have an example online somewhere? This might be useful to have as a reference in the future.
      - bodyfour 11y ago
        http://www.vtk.org/Wiki/CMake_Cross_Compiling http://www.vtk.org/Wiki/CMake_Cross_Compiling
    - deleted 11y ago
      [deleted]
    - tanderson92 11y ago
      Note that autotools handles all that (referencing also your link in another child comment) for you with no extra work. Writing a autoconf script for a native architecture means your project should compile for a cross arch. It is for that reason I much prefer autotools, especially at the distribution level where you really don't want to be patching things. CMake can work, but I have had to do more patching for CMake build systems than I have had to for autotools; on that basis I consider autotools "better", at least for our use case.
- danieldk 11y ago
  I came to the conclusion that CMake is more frustrating than Autotools when you need to do something unusual. Unusual in terms of...? If I have learnt anything from Go, Java (per Maven), etc. it's that the far majority of project don't need to do something unusual. Conversely, if you give people the room to do unusual things, they will.
- astrodust 11y ago
  CMake. Ugh. It solves some problems and creates many, many more in the process. There's a certain simplicity from the perspective of the user that configure && make && make install works most of the time. CMake requires a lot of effort to get running by comparison.
uxcn 11y ago
A lot even limit their codebases to C89, which I don't understand. Are there really that many platforms/compilers that don't effectively support C99 or greater? Is sixteen years not long enough for a language feature set to stabilize? Maybe there are tradeoffs or platforms I'm just not aware of, but I at least tend to use C99 as the LCD.
- realityking 11y ago
  That's mostly because of Microsoft's horribly outdated C-compiler
  - uxcn 11y ago
    Why would anyone use VS to compile cross-platform C on Windows when there's MinGW (and clang-cl)?
    - comex 11y ago
      Debug info, ubiquity, simplicity of combining with an otherwise VS based project. At least VS now supports most of C99. Most. Now about that C11...
      - uxcn 11y ago
        Having code that's easy to integrate with existing projects is definitely a really good thing, and I honestly don't like to neglect Windows, but with all due respect, the platform kind of does it to itself. C11 would be really nice to see as an LCD, especially for threading (or even just a native POSIX threads implementation).
        comex 11y ago
        I was more thinking of language features. threads.h would be nice, but, as you may know, despite it being a pretty simple API, neither glibc nor OS X libc has implemented it - there's only musl and then compatibility shims. Sigh. You could blame a lack of demand, but I'd call that chicken and egg: the whole advantage of it over pthreads in theory is portability due to standardization, but as long as the portability remains theory, so does the advantage.

kukkukb 11y ago

Wasn't this one of main reasons that thenNeoVim project was started?

stefantalpalaru 11y ago

> What platforms do we need to get rid of to get rid of autoconf/automake/configure and use e.g. CMake instead? Why would you want that? Autotools is the devil we know. CMake has its own problems and from a statistical sample of one project implementing both, I came to the conclusion that CMake is more frustrating than Autotools when you need to do something unusual.

tanderson92 11y ago
Exactly. autotools is exceptionally well designed for dealing with more exotic use cases like cross compiling. When designing a cross-compiling linux distribution(http://exherbo.org/docs/multiarch.txt http://exherbo.org/docs/multiarch.txt) we discovered that autotools is by far the easiest to deal with when it comes to arbitrary host & build targets, compilers, etc. I would be even bolder and say that: Those who do not understand autotools are doomed to reinvent it, poorly.
- danieldk 11y ago
  Exactly. autotools is exceptionally well designed for dealing with more exotic use cases like cross compiling. ...and it cannot deal with non-exotic use cases like non-UNIX environments (think Windows + Visual Studio) well at all. In contrast, with CMake you can generate an nmake file or Visual Studio project with one command.
  - JoshTriplett 11y ago
    On the other hand, with autotools you can cross-compile for Windows using MinGW.
    - Sanddancer 11y ago
      Just like someone under unix could always just use mono's xbuild to build a project using visual studio's .vsproj files. Course, people tend to get grumpy when you tell them that they have to jump through hoops to use your project, just like your suggestion...
- nitrogen 11y ago
  I use CMake to cross-compile firmware for my home automation hardware. It doesn't seem too bad, just a single file shared across all projects that defines the compiler binaries and settings. I like it much better than autotools.
  - detaro 11y ago
    Do you have an example online somewhere? This might be useful to have as a reference in the future.
    - bodyfour 11y ago
      http://www.vtk.org/Wiki/CMake_Cross_Compiling http://www.vtk.org/Wiki/CMake_Cross_Compiling
  - deleted 11y ago
    [deleted]
  - tanderson92 11y ago
    Note that autotools handles all that (referencing also your link in another child comment) for you with no extra work. Writing a autoconf script for a native architecture means your project should compile for a cross arch. It is for that reason I much prefer autotools, especially at the distribution level where you really don't want to be patching things. CMake can work, but I have had to do more patching for CMake build systems than I have had to for autotools; on that basis I consider autotools "better", at least for our use case.
danieldk 11y ago
I came to the conclusion that CMake is more frustrating than Autotools when you need to do something unusual. Unusual in terms of...? If I have learnt anything from Go, Java (per Maven), etc. it's that the far majority of project don't need to do something unusual. Conversely, if you give people the room to do unusual things, they will.
astrodust 11y ago
CMake. Ugh. It solves some problems and creates many, many more in the process. There's a certain simplicity from the perspective of the user that configure && make && make install works most of the time. CMake requires a lot of effort to get running by comparison.

uxcn 11y ago

A lot even limit their codebases to C89, which I don't understand. Are there really that many platforms/compilers that don't effectively support C99 or greater? Is sixteen years not long enough for a language feature set to stabilize? Maybe there are tradeoffs or platforms I'm just not aware of, but I at least tend to use C99 as the LCD.

realityking 11y ago
That's mostly because of Microsoft's horribly outdated C-compiler
- uxcn 11y ago
  Why would anyone use VS to compile cross-platform C on Windows when there's MinGW (and clang-cl)?
  - comex 11y ago
    Debug info, ubiquity, simplicity of combining with an otherwise VS based project. At least VS now supports most of C99. Most. Now about that C11...
    - uxcn 11y ago
      Having code that's easy to integrate with existing projects is definitely a really good thing, and I honestly don't like to neglect Windows, but with all due respect, the platform kind of does it to itself. C11 would be really nice to see as an LCD, especially for threading (or even just a native POSIX threads implementation).
      - comex 11y ago
        I was more thinking of language features. threads.h would be nice, but, as you may know, despite it being a pretty simple API, neither glibc nor OS X libc has implemented it - there's only musl and then compatibility shims. Sigh. You could blame a lack of demand, but I'd call that chicken and egg: the whole advantage of it over pthreads in theory is portability due to standardization, but as long as the portability remains theory, so does the advantage.