Announcement

Collapse
No announcement yet.

Autodafe 0.2 Released For Freeing Your Project From Autotools

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Blademasterz
    replied
    By getting rid of autotools, we ease the burden of distro mantainers

    Leave a comment:


  • JMB9
    replied
    As time flows by there is a new version 0.3 (released 9 hours ago) - for all people concerned about it.
    Here is the news output:


    I think this is just oldschool when people knew what they were doing - not depending on automatic routines
    which no one has checked or using binary blobs instead of clear scripts or clear source code.
    No simple Internet ready for just cut & paste without knowing anything - no smartphones to wipe things
    away of sight - no AI chat programs to get sentences formed out of garbage ...

    Linux standardized Unix systems a long way ago ... e.g. IBM AIX 5L was released 05/2001 - 23 years back
    in time. At that time simple make was still in use by a lot of programmers ...

    Thinking of the most important languages it is interesting how many people hate C or C++ - and
    Rust has not proven anything right now. But Cobol and Fortrun are still alive and kicking ...
    We will see if Rust will do it as some hope.

    Leave a comment:


  • edgmnt
    replied
    As far as I know (but haven't used it much), meson sidesteps the complexity of autodetection by requiring a build profile for the target at least for cross-compiling. Which makes a lot of sense, for the same reason you probably don't want stuff like -march=native. Sure, you still need to come up with a profile, but it can be gathered ahead of time and you can make it predictable and static. If you want it an exact fit to the machine, you can probably implement autodetection logic elsewhere.

    Autotools covered the niche where you simply downloaded a package to a random machine, possibly on a completely different OS nobody knew about, and it worked out of the box without much agreement on tooling. In fact, you didn't even need autotools because a generated, POSIX-compliant configure script was distributed. But that's kind of crazy, because you wouldn't be able to review such a script meaningfully.

    Leave a comment:


  • SophiaS
    replied
    Originally posted by Hazel View Post
    People should just migrate to cmake/mason
    "Just" is good. Try it with LibreOffice.

    Leave a comment:


  • SophiaS
    replied
    The largest project I know still relying on autotools is LibreOffice. Would love to see it building with Meson, CMake, whatever. Such tools are a nice playground (I am playing around with an own hacked version of auto2cmake in my local fork with it). Will give it a try. And yes, it is just for fun. I don't think I'll get it working.

    Leave a comment:


  • toves
    replied
    Autotools was very good at configuring build in quite diverse Unix (posix) environments most of which have now vanished. Pre-2000 you might have had a basic Unix System III derived system with various vendor modifications running on a proprietary CPU etc with possibly quite peculiar toolchains. The included software was normally quite mimimal and the vendor would nickel and dime* you for any add on software (including the toolchain.)
    Consequently otherwise identical systems diverged in the various layers off user built and installed software. This is the world in which autotools excelled.
    Autodafe appears to take advantage of the fact the world has crystallized into Linux and *BSD which are remarkably homogeneous - you can pretty much depend on gcc or a llvm compatible C compiler, the C standard libraries (a post 1990 luxury) , a posix interface (unistd.h) and so on.
    I imagine you can visualize autoafe taking the extremely versatile and dynamic autotools environment and applying static definitions from (linux/bsd/posix), optimizing (dead code elimination, etc) and emitting static Makefiles (nothing other than implicit rules, targets and dependencies, and flag (and other) definitions) which partially address the xz fiasco.
    For distros producing such Makefiles for the source packages could largely eliminated the need for autotools in the users build environment. Quite a few RPM spec files use autotools to configure their packages.

    The Mirriam Webster has -
    Auto-da-fe: the ceremony for pronouncing judgment by the Inquisition which was followed by the execution of sentence by secular authorities.
    broadly : the burning of a heretic

    * multiplied by several orders of magnitude.

    Leave a comment:


  • felipec
    replied
    Originally posted by jabl View Post
    Congratulations for engaging in pointless word-pedantery while completely missing the point.
    I'm sorry that you have trouble with words, but words matter. I did not say what you claimed I said.

    To make it even clearer: if you're looking for portability headaches
    I'm not. You are debating a straw man you invented in your head.

    locations of libraries and their headers etc.
    You don't need a build system for that, just use pkg-config.

    And given how common autotools, for better or worse, is, I'm quite sure there's loads of other examples.
    I'm not asking what you are "quite sure" of, I'm asking for actual instances of software in the real world that is checking for those precise HP-UX function signatures.

    No words, point to the actual configure.ac file of the actual project.​

    Leave a comment:


  • hsci
    replied
    I can only recommend everyone using C and C++ to use Meson. It is also usable with Rust and Java.

    * Readable and clean syntax. Scripting not required.
    * Built-in dependency management: host libraries, self declared dependencies or wrap-db.
    * Central, well maintained documentation.

    I can read and understand makefiles but reading a configure.ac, configure.sh or config.status from Autotools horrible. Furthermore the end-user interface consisting of autotools is also a problem because it is not clear when to use autogen.sh, autoreconf -i (probably right) and afterwards ./configure and only finally make. Therefore porting all of them directly to a single makefile is probably a step forward?

    Real world examples
    Autotools: configure.ac and autogen.sh and more (again: As far as I know you better use autoreconf)
    Meson: meson.build and src/meson.build (splitup between project setup and source is common common for large projects)
    Last edited by hsci; 19 April 2024, 10:41 AM.

    Leave a comment:


  • jabl
    replied
    Originally posted by billyswong View Post

    All these quirks are OS-specific and compiler-specific, but not software project specific. I stand by what I wrote earlier, which is whatever wrapper scripts for this kind of problems should have been done once per platform and shared by all projects. A proper "build system" should allow custom instructions only for testing and bootstrapping new platform versions. Each software projects maintaining their own quirk workarounds is absurd.
    Once again we're looking at the difference between the world as it is, and what someone thinks it should be. That a project like you envision doesn't exist might be a hint that the problem isn't as easy as you think it is.

    (And of course, not all checks need to be fully custom for each project. Autotools (via autoconf-archive), and cmake ship with a large set of builtin tests for various things, and of course many libraries provide stuff like pkg-config or cmake snippets that downstream consumers can use.)

    Leave a comment:


  • jabl
    replied
    Originally posted by felipec View Post
    I did not say it was particularly obscure, I said it was obscure, certainly more obscure than x86_64-linux-gnu.
    Congratulations for engaging in pointless word-pedantery while completely missing the point. To make it even clearer: if you're looking for portability headaches, anything running Linux and either glibc or musl isn't much of a problem (well, things like ASM optimization can of course be a problem for rarer HW architectures, but I'm talking about software API issues here, locations of libraries and their headers etc., things that a build system usable for portable software must be able to figure out).

    And how many projects out there did use autotools to build a threaded program for your platform successfully?
    I'm unsure what you mean by "your platform" here?

    Can you name even one?
    I guess that depends on what "your platform" above refers to. If you mean HP-UX, then yes the particular software I mentioned did use autotools so I guess that's at least one I can name. And given how common autotools, for better or worse, is, I'm quite sure there's loads of other examples. But in general, no sunshine, I'm not going to go and do your homework; if you want to prove something you go out and dig up the supporting data yourself.

    If you really must have a check -- which is rare in the first place, you can implement the check yourself, you don't need autocrap for that. That's how FFmpeg and QEMU do it.

    Are you going to claim FFmpeg doesn't have good platform support?
    I never said you must use autotools. I even specifically mentioned a couple of alternatives that I think are better. My argument is that given the reality of cross-platform development in languages like C and C++, a build tool that doesn't allow you to do various target checks at build time is crap and not worth spending your time on.

    As for FFmpeg and QEMU, I'm not familiar with the development of either of these two projects, but just for kicks I went and took a look at QEMU git. And lo and behold, they use meson (good for them!), with a lot of various target checks. Just like what you'd use autoconf for if the project were using autotools. Which is exactly my point: A good build system for the reality of cross-platform development needs the ability to have build-time checks of the target.
    Last edited by jabl; 19 April 2024, 08:29 AM.

    Leave a comment:

Working...
X