4 ms·

CMake is really more of a C++ crowd thing, it never won the mindshare with C. > I don't really see why anyone would pick autoconf for a modern project. If you

by varjag 2y ago

CMake is really more of a C++ crowd thing, it never won the mindshare with C. > I don't really see why anyone would pick autoconf for a modern project. If you build for your system only and never ever plan to cross compile by all means go with static makefile.

fc417fc802 2y ago
A few of my personal projects cross compile via static makefile. Is there something wrong with that?
- deleted 2y ago
  [deleted]
- kazinator 2y ago
  If you're not writing something which compiles its own tools which are then used for the rest of the build, or is not a compiled programming language, all you have to do is respect the CC, CFLAGS, LDFLAGS and LDLIBS variables coming from the distro. Then you will use the correct cross toolchain and libs. If you need to compile programs that run on the build machine, you should have a ./configure script which allows a host CC and target CC to be specified, and use them accordingly. Even if you deviate a bit from what others are doing, if it is clearly documented and working, the downstream package maintainer can handle it.
kazinator 2y ago
A good way to make sure your project won't cross compile is to use Autoconf. Rampant use of Autoconf is the main reason distros gave up on cross compiling and started using QEMU. Developers who use Autoconf and who don't know what cross-compiling is will not end up with a cleanly cross-compiling project that downstream packagers don't have to patch into submission. Most of my disdain for Autoconf was formed when I worked at a company where I developed a embedded Linux distro from scratch. I cross-compiled everything. Most of the crap I had to fight with was Autoconf projects. I was having to do things like export various ac_cv_... internal variables that nobody should know about, and patching configure scripts themselves. Fast forward a few years and I see a QEMU everywhere for "cross" builds. The rest of my disdain comes from having worked with the internals of various GNU programs. To bootstrap their build systems from a repository checkout (not a release tarball) you have to follow their specific instructions. Of course you must have the Autotools installed. But there are multiple versions, and they generate different code. For each program you have to have the right version that it wants. If you have to do a git bisect, older commits may need an older version of the Autotools. Bootstrap from the configure system from scratch, the result of which is the privilege to now run configure from scratch. It's simply insane. You learn things like to touch certain files in a certain order to prevent a reconfigure that has about a 50% chance of working. Let's not even going to libtool. The main idea behind Autoconf is political. Autoconf based programs are deliberately intended to hinder those who are able to build a program on a non-GNU system and then want to make contributions while just staying on that system, not getting a whole GNU environment. What I want is something different. I want a user to be able to use any platform where the program works to obtain a checkout if exactly what is in git, and be able to make a patch to the configuration stuff, test it and send upstream without installing anything that is not required for just building the program for use.
- pabs3 2y ago
  Autoconf and automake has the best support for cross-compiling there is, everything else is a poor imitation. At least from the perspective of the folks doing Debian's cross-build stuff. With Debian's multi-arch policy, cross-toolchain packages and dpkg-dev/debhelper support for driving common cross-compiling options, plus fixing a ton of edge cases, IIRC more than 50% of Debian packages are now cross-compilable without qemu. Often they are bit-for-bit identical to the native compilation too. https://wiki.debian.org/CrossCompiling https://wiki.debian.org/CrossCompiling https://crossqa.debian.net/ https://crossqa.debian.net/
  - kazinator 2y ago
    A build system has great support for cross compilation when downstream package maintainers don't have to lift a finger to make it work, even though the upstream developer has not even tried cross compiling.
    - pabs3 2y ago
      Its inevitable that upstream devs will use even the best build system incorrectly, resulting in downstream needing to make changes to fix things. This is the reality of what happens with both autotools and every other build system that supports cross compiling.
      - deleted 2y ago
        [deleted]
- varjag 2y ago
  > A good way to make sure your project won't cross compile is to use Autoconf. Yeah well this is not quite true. Most embedded distros leverage autotools heavily. In Yocto you just specify autotools as the package class for the recipe and in most cases it will pull, cross compile and package the piece of software for you with no intervention. The tools are clearly antiquated, written in a questionable taste and 80% of the cases they solve are no longer relevant. They are still very useful for the rest.

by varjag 2y ago

fc417fc802 2y ago

A few of my personal projects cross compile via static makefile. Is there something wrong with that?

deleted 2y ago
[deleted]
kazinator 2y ago
If you're not writing something which compiles its own tools which are then used for the rest of the build, or is not a compiled programming language, all you have to do is respect the CC, CFLAGS, LDFLAGS and LDLIBS variables coming from the distro. Then you will use the correct cross toolchain and libs. If you need to compile programs that run on the build machine, you should have a ./configure script which allows a host CC and target CC to be specified, and use them accordingly. Even if you deviate a bit from what others are doing, if it is clearly documented and working, the downstream package maintainer can handle it.

kazinator 2y ago

A good way to make sure your project won't cross compile is to use Autoconf. Rampant use of Autoconf is the main reason distros gave up on cross compiling and started using QEMU. Developers who use Autoconf and who don't know what cross-compiling is will not end up with a cleanly cross-compiling project that downstream packagers don't have to patch into submission. Most of my disdain for Autoconf was formed when I worked at a company where I developed a embedded Linux distro from scratch. I cross-compiled everything. Most of the crap I had to fight with was Autoconf projects. I was having to do things like export various ac_cv_... internal variables that nobody should know about, and patching configure scripts themselves. Fast forward a few years and I see a QEMU everywhere for "cross" builds. The rest of my disdain comes from having worked with the internals of various GNU programs. To bootstrap their build systems from a repository checkout (not a release tarball) you have to follow their specific instructions. Of course you must have the Autotools installed. But there are multiple versions, and they generate different code. For each program you have to have the right version that it wants. If you have to do a git bisect, older commits may need an older version of the Autotools. Bootstrap from the configure system from scratch, the result of which is the privilege to now run configure from scratch. It's simply insane. You learn things like to touch certain files in a certain order to prevent a reconfigure that has about a 50% chance of working. Let's not even going to libtool. The main idea behind Autoconf is political. Autoconf based programs are deliberately intended to hinder those who are able to build a program on a non-GNU system and then want to make contributions while just staying on that system, not getting a whole GNU environment. What I want is something different. I want a user to be able to use any platform where the program works to obtain a checkout if exactly what is in git, and be able to make a patch to the configuration stuff, test it and send upstream without installing anything that is not required for just building the program for use.

pabs3 2y ago
Autoconf and automake has the best support for cross-compiling there is, everything else is a poor imitation. At least from the perspective of the folks doing Debian's cross-build stuff. With Debian's multi-arch policy, cross-toolchain packages and dpkg-dev/debhelper support for driving common cross-compiling options, plus fixing a ton of edge cases, IIRC more than 50% of Debian packages are now cross-compilable without qemu. Often they are bit-for-bit identical to the native compilation too. https://wiki.debian.org/CrossCompiling https://wiki.debian.org/CrossCompiling https://crossqa.debian.net/ https://crossqa.debian.net/
- kazinator 2y ago
  A build system has great support for cross compilation when downstream package maintainers don't have to lift a finger to make it work, even though the upstream developer has not even tried cross compiling.
  - pabs3 2y ago
    Its inevitable that upstream devs will use even the best build system incorrectly, resulting in downstream needing to make changes to fix things. This is the reality of what happens with both autotools and every other build system that supports cross compiling.
    - deleted 2y ago
      [deleted]
varjag 2y ago
> A good way to make sure your project won't cross compile is to use Autoconf. Yeah well this is not quite true. Most embedded distros leverage autotools heavily. In Yocto you just specify autotools as the package class for the recipe and in most cases it will pull, cross compile and package the piece of software for you with no intervention. The tools are clearly antiquated, written in a questionable taste and 80% of the cases they solve are no longer relevant. They are still very useful for the rest.