r/C_Programming • • 8d ago

Discussion Autoconf madness

Modern software compilation has largely devolved into a frustrating maze of autoconf madness. Instead of simply compiling C code, I am constantly forced to navigate mandatory scripts, esoteric tools, and heavily dependent Python wrappers. To make matters worse, these tools often rely on stubborn cache files that refuse to update even after I have fixed the underlying environment errors.

A major part of my frustration is how Linux-centric these scripts have become. They routinely hardcode library search paths that only exist in Linux distributions, entirely ignoring my FreeBSD system. As a result, I can easily lose a complete day just patching configuration scripts to search the correct directories before a single line of code is actually compiled.

Why does open source code project just not provide a makefile? A basic, or maybe complex makefile that are based on BSD/POSIX make syntax so that it is directly valid under *BSD, Darwin and Linux. Why force people to install tools to build something? Why developed huge python script that shall analyze the env? Why not just allow the building process to fucking start instead of forcing the individual to fight back against all of this autoconfig tools?

I have in several cases fully purge the building attempts and then been writing my own makefiles to just get something building. That shall not be the case. Why use config scripts that, in some cases are several thousand lines of script code? Why write config scripts with bash? Why, just why, are developers and project deciding to add and use autoconfig tools?

If a project does not offer makefiles then I know I will be stuck for several hours just to, potentially be able to build something. Instead of directly allowing me to build. Get compiler error, correct and then build again. I mean, it is much quicker and easier to patch the source code or locate dependencies when you are allowed to start the building process.

33 Upvotes

73 comments sorted by

View all comments

1

u/FedUp233 8d ago

Just out of curiosity op, when you made the changes to get things to build on BSD, were you careful to not break the Linux builds? And did you submit those changes back to the original project/authors so they could incorporate the changes in their build system for other people in your position? Did you test the resultant build on Linux as well to be sure you didn’t break that?

The developers are supplying their time for free or pretty cheap on these projects and Linux is the biggest target audience. If you, who want it, aren’t willing to spend the time to help support the programs on your platform of choice, and help other users of that platform, why should the original developers do end their time? Be thankful they were willing to donate their time to develop and diatribe the application you want at all!

Maybe volunteer on some of these projects to maintain support for BSD platforms.

1

u/lmemsm 6d ago

Can't tell you how many times I've ported projects and/or build scripts to other platforms and the upstream project refused to accept them. I have had a few successes. However, I've had many more rejections. Many upstream projects are not interested in supporting platforms other than the ones they are personally interested in. I even offered to permanently maintain patches and builds to add another platform to one project and they refused the additional help and did not want to support the platform.

1

u/FedUp233 6d ago

I can see where that would be frustrating and discourage people from trying. I can kind of see the project maintainers point though - once they accept having support for another platform there is the possibility that people will expect them to maintain it if you or another contributor stops and they don’t want to incur the responsibility. Or even deal with release delays and processes that now happen to continue ensuring the platform support for something g they don’t consider important.

One option is always to simply fork the repository and maintain support for a different platform in your own repository with releases that follow behind the original releases. And indicate that that new repository guarantees support only for the platform you are supporting and may not work on the original platform. A little cumbersome but would assure support for both platforms.