4 ms·

And yet most contemporary hipster build systems are all just shiny make reinventions.

badman_ting 13y ago
Good enough for me.
matt__rose 13y ago
Actually, most contemporary hipster build systems are bad reimplementations of make. Yes, make is a PITA, but every other build system is worse.
- nailer 13y ago
  UI have yet to see a 'hipster build system' that mixes shell and make language or uses punctuation for variables. Are all things made since 1977 hipster?
  - ahknight 13y ago
    Yes. Get off my lawn, hippie.
Touche 13y ago
Reinventions that are cross-platform (this actually matters).
- oijaf888 13y ago
  What platforms doesn't make support? AFAIK GNU make supports pretty much everything and there are versions of make for Solaris/BSDs.
  - GeneralMayhem 13y ago
    Make exists everywhere, but you have to explicitly write separate rules for every system.
- lmm 13y ago
  Auto* is still the most cross-platform build system I've ever used. It let me compile a project from 2003 on windows vista; how many other systems can you say that for?
Nemcue 13y ago
Most new things are inspired by something else to the extent that they can be viewed as reinventions. So that's a moot point, and doesn't contribute at all.
danieldk 13y ago
My preferred hipster build system (CMake) actually leverages make on UNIX platforms and nmake on Windows :). It just replaces the most of the autoconf mess.
- matthiasv 13y ago
  > It just replaces the most of the autoconf mess. With a non-standard mess on its own ... CMake is pretty bad at doing things (standard paths, install targets etc.) that the GNU folks solved a long time ago. Yes, the Autotools are a royal PITA but at least a pain that one knows how to deal with.
  - jibsen 13y ago
    CMake certainly has its own set of peculiarities, but sometimes it can work to let you build stuff on Windows with VC++ or plain MinGW without having to use MSYS/Cygwin. Creating portable software and then distributing it with a Posix only build system seems wasteful.
  - danieldk 13y ago
    With a non-standard mess on its own ... Perhaps, but not any that I have had problems with. E.g. an application that we distribute uses Qt, Boost, Berkeley DB XML, libxml2, libxslt, etc. Producing signed application bundles for OS X, MSI installers for Windows, and packages for Ubuntu has been nearly painless. And that's with clang on OS X, Visual C++ on Windows, and gcc on Linux. If it's easy to produce binaries on the three most popular platforms, with three different compilers, I don't see the problem. We have tried autotools before. But it's a pain on Windows with Visual Studio. Let alone that I can quickly generate a Visual Studio project to do some debugging.
    - matthiasv 13y ago
      Sure, if you do the packaging for a restricted set of environments yourself, CMake certainly works fine. I do the same for a lot of projects and know what CMake is capable of. But when it comes to the differences between all those Linux distributions, the respective packager will be very glad to see that he can customize install prefixes (no, CMAKE_INSTALL_PREFIX is not enough) and use standard make targets. Your list of dependencies shows libraries that are well covered by the stock CMake modules but try getting a build variable that is not LIBS or CFLAGS from a library that can only be queried with pkg-config. Impossible.

Good enough for me.

Actually, most contemporary hipster build systems are bad reimplementations of make. Yes, make is a PITA, but every other build system is worse.

nailer 13y ago
UI have yet to see a 'hipster build system' that mixes shell and make language or uses punctuation for variables. Are all things made since 1977 hipster?
- ahknight 13y ago
  Yes. Get off my lawn, hippie.

Touche 13y ago

Reinventions that are cross-platform (this actually matters).

oijaf888 13y ago
What platforms doesn't make support? AFAIK GNU make supports pretty much everything and there are versions of make for Solaris/BSDs.
- GeneralMayhem 13y ago
  Make exists everywhere, but you have to explicitly write separate rules for every system.
lmm 13y ago
Auto* is still the most cross-platform build system I've ever used. It let me compile a project from 2003 on windows vista; how many other systems can you say that for?

Nemcue 13y ago

Most new things are inspired by something else to the extent that they can be viewed as reinventions. So that's a moot point, and doesn't contribute at all.

danieldk 13y ago

My preferred hipster build system (CMake) actually leverages make on UNIX platforms and nmake on Windows :). It just replaces the most of the autoconf mess.

matthiasv 13y ago
> It just replaces the most of the autoconf mess. With a non-standard mess on its own ... CMake is pretty bad at doing things (standard paths, install targets etc.) that the GNU folks solved a long time ago. Yes, the Autotools are a royal PITA but at least a pain that one knows how to deal with.
- jibsen 13y ago
  CMake certainly has its own set of peculiarities, but sometimes it can work to let you build stuff on Windows with VC++ or plain MinGW without having to use MSYS/Cygwin. Creating portable software and then distributing it with a Posix only build system seems wasteful.
- danieldk 13y ago
  With a non-standard mess on its own ... Perhaps, but not any that I have had problems with. E.g. an application that we distribute uses Qt, Boost, Berkeley DB XML, libxml2, libxslt, etc. Producing signed application bundles for OS X, MSI installers for Windows, and packages for Ubuntu has been nearly painless. And that's with clang on OS X, Visual C++ on Windows, and gcc on Linux. If it's easy to produce binaries on the three most popular platforms, with three different compilers, I don't see the problem. We have tried autotools before. But it's a pain on Windows with Visual Studio. Let alone that I can quickly generate a Visual Studio project to do some debugging.
  - matthiasv 13y ago
    Sure, if you do the packaging for a restricted set of environments yourself, CMake certainly works fine. I do the same for a lot of projects and know what CMake is capable of. But when it comes to the differences between all those Linux distributions, the respective packager will be very glad to see that he can customize install prefixes (no, CMAKE_INSTALL_PREFIX is not enough) and use standard make targets. Your list of dependencies shows libraries that are well covered by the stock CMake modules but try getting a build variable that is not LIBS or CFLAGS from a library that can only be queried with pkg-config. Impossible.