11–20 of 57 posts
This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rather baroque, and there are many other choices these days that provide similar functionality for less developer time and effort.
This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rather baroque, and there are many other choices these days that provide similar functionality for less developer time and effort.
Could you provide some examples of other choices that you speak of? Thank you.
This is awesome. Have just been strugglingh to get started with this the past few evenings. Will take this as my guide. Thanks for posting! BTW, good place to start learning the relevant parts of GCC?
This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rather baroque, and there are many other choices these days that provide similar functionality for less developer time and effort.
Could you provide some examples of other choices that you speak of? Thank you.
Earlier quoted context omitted.
To elaborate on "baroque": autotools spends a lot of time and effort on detecting behaviours which (a) no new Unix system has exhibited for at least two decades, and (b) your code almost certainly isn't going to be able to handle anyway. Autotools was great once, but the world has moved on. Write code which is POSIX compliant and skip the whole mess.
As a user building packages I like autotools because of its uniformity. If I want to change the install root I use "--prefix". If I want to crosscompile I can set "--build" and "--host". If I need to set a compiler flag, autotools actually observes CFLAGS. A few years ago I was trying to install a python extension and I couldn't figure out how to set a cflag on the native code it was compiling. It ignored CC, CFLAGS,…
This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rather baroque, and there are many other choices these days that provide similar functionality for less developer time and effort.
What the Autotools could benefit greatly from is a new UI. We can all agree that M4 sucks big time.
This is awesome. Have just been strugglingh to get started with this the past few evenings. Will take this as my guide. Thanks for posting! BTW, good place to start learning the relevant parts of GCC?
If youre just starting something and not maintaining something older you should really take a look into CMake
Yes, I am just starting something small and new. And am now jumping the cliff of learning C, gcc, make, autotools, and gnulib-tool, of course all at the same time. Talking about a heap overflow ;)
Is it correct that CMake is a replacement for GNU Make? So far, GNU Make has not posed a problem. Can CMake assume some roles of the other tools as well? I am looking to have this interesting ride a little less bumpy.
Not coming from active c/cpp development, but learned it at University, I had to deal with autotools just last week. I have to admit I was facing a steep learning curve. All I wanted to do is adjusting some build parameters of an existing OS project (like adding compiler flags etc), which has several sub projects and is also calling non cpp-compilers (mono). Normally I'm an extremely fast learner, but this gave me so…
./configure CC=gcc44 CXX=g++44 CFLAGS="-m32" CXXFLAGS="-m32"
This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rather baroque, and there are many other choices these days that provide similar functionality for less developer time and effort.
Could you provide some examples of other choices that you speak of? Thank you.