Alternative perspective: Why is make your newest dependency? It is a very uninteresting part of a project and you can target a slightly older version.
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
That's usually true except that this project is about the Makefile itself 😁 I'm working on a set of useful recipes, targets and variables which I've always missed from Make's out-of-the-box offering - something like a stdlib/utils for Make.
And yes, as you may have already guessed, I've had to deal w/ Makefiles relatively frequently 😀
For posterity, I settled down on compiling Gnu Make 4.4 as part of the pipeline. It turned out to be a really quick step and not a trouble at all - takes 10-15s only!
On another note: thank you Gnu Make maintainers ❤️
Is there a reason for using Travis instead of GitHub's built-in CI system?
With the GitHub CI system, you can specify your own container image which could have GNU Make 4.4 already pre-installed (you build it once and then re-use it).
RE Travis: I feel quite comfortable and happy w/ Travis already. Additionally, I want to keep my reliance on github minimal. The only reason I'm using it is that it is where things are searched for and found by fellow programmers :-)
RE Container: My home machine is running Tumbleweed which's had Gnu Make 4.4 for a few months now already. I was trying to make the pipeline behave as closely as possible to the user's machine who may not have that version installed. Otherwise as you and @sugar_in_your_tea@sh.itjust.works mentioned, I could pack everything I'd need in a container.
You'd just use the container for testing other Make versions. If your users use Ubuntu, run your tests with an Ubuntu docker image. You can run several versions that way with minimal effort.
I don't know much about Travis, but it's pretty easy to set that up with Jenkins.
That's pretty much what I ended up doing. Install Gnu Make 4.4 as part of the pipeline. I then added a check to warn the user if the Make version they use is not supported.
No, I'm saying you'd support older versions of make in your project and use docker images in your CIb pipeline to test each of those supported versions. If you're not using any 4.4-specific features, 4.2 (20.04) and 4.3 (22.04) would probably work. So you'd have a docker container for every OS that you're officially supporting (or at least every version of make that supported OSes use).
I see your point. Though the main thing, as I mentioned in the question, is that I'm using features from 4.4 so that strategy wouldn't work for me.