5 ms·

Uhm, "modern" and "built using GNU Autotools" in a single sentence just doesn't compute. Cross-platform portability obviously isn't their goal. Oh and thank y

by janoc 11y ago

Uhm, "modern" and "built using GNU Autotools" in a single sentence just doesn't compute. Cross-platform portability obviously isn't their goal. Oh and thank you for removing moc and replacing that with some template black magic. Yeah, you can do that, but your developers are going swear up a storm at you once they see the wonderful compilation errors that e.g. MSVC produces with templates ... But I guess they don't target professional Windows devs (cf the MinGW compilation ...). This looks very much like a classic not-invented-here syndrome project - "let's make something better by throwing out everything that made it useful". I do wonder what is the raison d'être of this project.

easytiger 11y ago
> Uhm, "modern" and "built using GNU Autotools" Autotools represents a pragmatic solution to a non trivial problem. What's your solution? Hipster like complaining? Perhaps the c/c++ eco system is too easy and straightforward for the hipster developer class?
- janoc 11y ago
  Before you call someone "hipster", I suggest you actually learn something about the problem. CMake is the defacto standard for building portable C/C++ software today, there is also SCons. In fact, Qt includes its own build system called qmake. All of these offer much more than the GNU Autotools ever did. So why do these things exist when autotools are so wonderful? Well, autotools are a damn nightmare to maintain (m4 scripts anyone?) and next to impossible to use outside of the GNU ecosystem - try to use it on Windows or Android without crutches like MinGW or Cygwin. Basically, an autotools build system is pretty much unusable except on a POSIX/Unix-like platform and even then it handles only building of the package. Not a proper installation support (e.g. support for installer building/packaging), no tests, no continuous integration/compile farm support, poorly written m4 code breaks parallel compilation, etc.
- berkut 11y ago
  Use something like CMake which is cross-platform, works very well in most cases and a lot of cross-platform open-source C++ libs are using already.
  - punch_card 11y ago
    CMake. Making easy things easy and hard things impossible. Provided most cases are easy, an acceptable solution.
    - janoc 11y ago
      Hmm, any examples for the impossible hard things? Or are you just trolling?
      - berkut 11y ago
        I think CMake is one of the best (not saying it's perfect) C/C++ build systems I've used (used jam, make, automake, qmake, scons quite comprehensively, either via choice or under duress), and there are some things that are close to impossible (or were a few years ago). One of these was getting an executable that's built as part of a script to generate a .cpp which is then built as another lib as a further dependency within the same build - I believe that's possible now as OpenEXR does it. Similarly, I've had to run external programs that binary patch executables and had serious issues doing that.
        janoc 11y ago
        That isn't all that hard to do, CMake routinely supports this for e.g. Swig or Qt's moc/uic/rcc tools. The code generator creates a bunch of files and those can be either built as a library or added to your normal list of sources.
lmm 11y ago
> Cross-platform portability obviously isn't their goal. As someone who runs a couple of obscure platforms, I swear every time I have to use a non-Autotools project. Autotools may be slow and may check for seventeen different fortran compilers even if your project never uses fortran, but portability-wise it simply works.
- janoc 11y ago
  I suggest that everyone defending Autotools in this day and age actually reads one of these blogs (and check the date on them!): http://freecode.com/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system http://freecode.com/articles/stop-the-autoconf-insanity-why-... http://www.shlomifish.org/open-source/anti/autohell/ http://www.shlomifish.org/open-source/anti/autohell/ That should give you the idea why Autoconf/Automake setups are past their sell-by date. For more than a decade.
  - amyjess 11y ago
    CMake is so wonderful. There's no reason to use it over autotools.
  - lmm 11y ago
    I'm not unaware of those. Much of the first article's claims are simply false, and the second article's claims that CMake breaks less often than auto* are, uh, not borne out by my experience. (CMake is by no means the worst though; if you must use something non-autotools CMake is probably the best option). The facts simply don't match the rhetoric.
asermersheim 11y ago
Cross platform portability is a major goal of the CopperSpice project. Autotools may be old but it still beats its competitors for portability to obscure platforms. We have removed moc and added templates but it is by no means black magic. The complexities are below the surface and we worked very hard to create a clean API for developers. Since you mention you are on MSVC which is a bit behind the curve in standards compliance, you may be unaware of the wonderful tools that C++11 now provides for generating simple and readable template error messages. We have made extensive use of static assertions for specifically this reason. The vast majority of errors are quite straightforward. As a bonus, many conditions which are run time errors in Qt are caught and diagnosed at compile time in CopperSpice. I will take a compile error, however inscrutable, over a guaranteed runtime failure any day.
- janoc 11y ago
  Well, unfortunately the fact the clang/llvm generates nice looking error messages doesn't help Windows developers using Visual C++ at all. And obscure platforms - are you targetting those as a priority? That could explain your choice of build system. On the other hand, the obscure platforms tend to have old, noncompliant C++ compilers and STL, so I am not completely sure how is that going to work together with your C++11 requirement. For me an "obscure platform" would be something like an IRIX 6.5, Solaris or some embedded hardware. Good luck with requiring C++11 there. Of course, you could be targeting an obscure platform in the sense that it is one of the few that actually ships with fully C++11 compliant compiler, but then good luck with wide adoption of your software ... Re compile errors vs runtime errors - agreed, even though most runtime errors related to moc in Qt are things like connecting to non-existing slot. That generates only an error message in console/log, it is not a fatal error. However, moc gets you faster compilation time (heavily templated C++ takes ages to compile - just look at Boost) and more readable/idiomatic code. And then there is the portability issue to older compilers - templates were traditionally the poster child for poor/incomplete implementations by the compiler vendors.

by janoc 11y ago

easytiger 11y ago

> Uhm, "modern" and "built using GNU Autotools" Autotools represents a pragmatic solution to a non trivial problem. What's your solution? Hipster like complaining? Perhaps the c/c++ eco system is too easy and straightforward for the hipster developer class?

janoc 11y ago
Before you call someone "hipster", I suggest you actually learn something about the problem. CMake is the defacto standard for building portable C/C++ software today, there is also SCons. In fact, Qt includes its own build system called qmake. All of these offer much more than the GNU Autotools ever did. So why do these things exist when autotools are so wonderful? Well, autotools are a damn nightmare to maintain (m4 scripts anyone?) and next to impossible to use outside of the GNU ecosystem - try to use it on Windows or Android without crutches like MinGW or Cygwin. Basically, an autotools build system is pretty much unusable except on a POSIX/Unix-like platform and even then it handles only building of the package. Not a proper installation support (e.g. support for installer building/packaging), no tests, no continuous integration/compile farm support, poorly written m4 code breaks parallel compilation, etc.
berkut 11y ago
Use something like CMake which is cross-platform, works very well in most cases and a lot of cross-platform open-source C++ libs are using already.
- punch_card 11y ago
  CMake. Making easy things easy and hard things impossible. Provided most cases are easy, an acceptable solution.
  - janoc 11y ago
    Hmm, any examples for the impossible hard things? Or are you just trolling?
    - berkut 11y ago
      I think CMake is one of the best (not saying it's perfect) C/C++ build systems I've used (used jam, make, automake, qmake, scons quite comprehensively, either via choice or under duress), and there are some things that are close to impossible (or were a few years ago). One of these was getting an executable that's built as part of a script to generate a .cpp which is then built as another lib as a further dependency within the same build - I believe that's possible now as OpenEXR does it. Similarly, I've had to run external programs that binary patch executables and had serious issues doing that.
      - janoc 11y ago
        That isn't all that hard to do, CMake routinely supports this for e.g. Swig or Qt's moc/uic/rcc tools. The code generator creates a bunch of files and those can be either built as a library or added to your normal list of sources.

lmm 11y ago

> Cross-platform portability obviously isn't their goal. As someone who runs a couple of obscure platforms, I swear every time I have to use a non-Autotools project. Autotools may be slow and may check for seventeen different fortran compilers even if your project never uses fortran, but portability-wise it simply works.

janoc 11y ago
I suggest that everyone defending Autotools in this day and age actually reads one of these blogs (and check the date on them!): http://freecode.com/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system http://freecode.com/articles/stop-the-autoconf-insanity-why-... http://www.shlomifish.org/open-source/anti/autohell/ http://www.shlomifish.org/open-source/anti/autohell/ That should give you the idea why Autoconf/Automake setups are past their sell-by date. For more than a decade.
- amyjess 11y ago
  CMake is so wonderful. There's no reason to use it over autotools.
- lmm 11y ago
  I'm not unaware of those. Much of the first article's claims are simply false, and the second article's claims that CMake breaks less often than auto* are, uh, not borne out by my experience. (CMake is by no means the worst though; if you must use something non-autotools CMake is probably the best option). The facts simply don't match the rhetoric.

asermersheim 11y ago

Cross platform portability is a major goal of the CopperSpice project. Autotools may be old but it still beats its competitors for portability to obscure platforms. We have removed moc and added templates but it is by no means black magic. The complexities are below the surface and we worked very hard to create a clean API for developers. Since you mention you are on MSVC which is a bit behind the curve in standards compliance, you may be unaware of the wonderful tools that C++11 now provides for generating simple and readable template error messages. We have made extensive use of static assertions for specifically this reason. The vast majority of errors are quite straightforward. As a bonus, many conditions which are run time errors in Qt are caught and diagnosed at compile time in CopperSpice. I will take a compile error, however inscrutable, over a guaranteed runtime failure any day.

janoc 11y ago
Well, unfortunately the fact the clang/llvm generates nice looking error messages doesn't help Windows developers using Visual C++ at all. And obscure platforms - are you targetting those as a priority? That could explain your choice of build system. On the other hand, the obscure platforms tend to have old, noncompliant C++ compilers and STL, so I am not completely sure how is that going to work together with your C++11 requirement. For me an "obscure platform" would be something like an IRIX 6.5, Solaris or some embedded hardware. Good luck with requiring C++11 there. Of course, you could be targeting an obscure platform in the sense that it is one of the few that actually ships with fully C++11 compliant compiler, but then good luck with wide adoption of your software ... Re compile errors vs runtime errors - agreed, even though most runtime errors related to moc in Qt are things like connecting to non-existing slot. That generates only an error message in console/log, it is not a fatal error. However, moc gets you faster compilation time (heavily templated C++ takes ages to compile - just look at Boost) and more readable/idiomatic code. And then there is the portability issue to older compilers - templates were traditionally the poster child for poor/incomplete implementations by the compiler vendors.