What do people think of 'tup'?
Time for Makefiles to Make a Comeback
41–50 of 116 posts
Re: Time for Makefiles to Make a Comeback
#42If you compare Makefiles to the JavaScript ecosystem it will do so favorably, but many things will. Make is a good build system but it is a shitty deployment system. Yes, you can do everything you want if you put enough effort in it as it is a complete scripting system, something many alternatives are not. It does not mean that it is a good idea to do so. Recently a client made me begrudgingly try Maven. 'Yet another…
Make isn't intended to be used for dependency management. With traditional `./configure && make && make install`, dependencies are detected by the configure script, or manually provided by the user if they have custom library paths. Dependencies are handled by your package manager or something else (be it submodules in git, custom scripts, etc). There's a separation of concerns. For generating those configure files,…
That's a rather dated view of what a build system should be. Most developers these days don't want to have to manually install all of a projects dependencies in order to build it. More importantly, there's also been a push towards wherever possible installing dependencies into sandboxes to try to prevent things like DLL hell, which isn't possible if you install dependencies at the OS level. I much rather just check out a project and run its build system to fetch all the dependencies instead of what we used to have to do with C projects, which is go read the docs to find the list of mandatory and optional dependencies, then go look through the distribution package manager to try to match up package names with library names (including a few head scratchers where something is included inside of a differently named package), and finally install the whole mess and hope that the projects config script properly finds them all.
Re: Time for Makefiles to Make a Comeback
#43If you compare Makefiles to the JavaScript ecosystem it will do so favorably, but many things will. Make is a good build system but it is a shitty deployment system. Yes, you can do everything you want if you put enough effort in it as it is a complete scripting system, something many alternatives are not. It does not mean that it is a good idea to do so. Recently a client made me begrudgingly try Maven. 'Yet another…
Make isn't intended to be used for dependency management. With traditional `./configure && make && make install`, dependencies are detected by the configure script, or manually provided by the user if they have custom library paths. Dependencies are handled by your package manager or something else (be it submodules in git, custom scripts, etc). There's a separation of concerns. For generating those configure files,…
Yes Make does one thing and one thing well.
Having said that, if you really want to manage dependencies with Make, it's still trivial to do a curl/yum/rpm install when some component is missing. I've done that in the form of a `make deps` pseudo-target, to prevent doing anything that the user doesn't expect.
Re: Time for Makefiles to Make a Comeback
#44For a better "make" try "do" (also known as "DJB redo"). It's designed by Dan Bernstein of crypto fame and implemented by Avery Pennarun now at Google. http://apenwarr.ca/log/?m=201012#14 I will contribute $100 to any Rust leader who wants to start coding "do" in Rust.
+1 for do/redo. Although it can be a bugger to get right for go (because there's no intermediate files) (although I think I've solved that now.)
Re: Time for Makefiles to Make a Comeback
#45Earlier quoted context omitted.
Make isn't intended to be used for dependency management. With traditional `./configure && make && make install`, dependencies are detected by the configure script, or manually provided by the user if they have custom library paths. Dependencies are handled by your package manager or something else (be it submodules in git, custom scripts, etc). There's a separation of concerns. For generating those configure files,…
That's a rather dated view of what a build system should be. Most developers these days don't want to have to manually install all of a projects dependencies in order to build it. More importantly, there's also been a push towards wherever possible installing dependencies into sandboxes to try to prevent things like DLL hell, which isn't possible if you install dependencies at the OS level. I much rather just check o…
> That's a rather dated view of what a build system should be
The author mentions JavaScript, which has npm as the package manager, which isn't a build system. It can _invoke_ a build system, but the build output produced is separately published to npm, or the build is triggered by e.g. a post-install hook.
I use GNU Make with npm. Some use e.g. Grunt. Etc.
> More importantly, there's also been a push towards wherever possible installing dependencies into sandboxes to try to prevent things like DLL hell, which isn't possible if you install dependencies at the OS level.
Make has been used this way for quite some time. Debian has its reproducible builds project. GNU Guix builds everything in an isolated environment, and even handles multiple versions of multiple packages---if you have five different packages that each depend on five different versions of the same library, then it'll install five different versions of the library and work just fine.
> I much rather just check out a project and run its build system to fetch all the dependencies instead of what we used to have to do with C projects
Make is just _part_ of a build system---it isn't necessarily one in itself. Some projects might use it exclusively in their build system, but others use a suite of tools. I use Autoconf (which generates configure) and Automake, which in turn generates a Makefile with all standard targets. If you check out a git repository for one of my JS projects, you run `npm install` to get the dependencies before building. Usually they're runtime dependencies, though, so they're not needed for the build. Other dependencies are detected via the configure script (e.g. I use graphviz for certain project, and the script makes sure it's installed and supports the feature I need).
Re: Time for Makefiles to Make a Comeback
#46I've been using make files constantly since '76 when I first started programming in (US) 5th grade. It has been one of my career amusements watching the build systems come and go. I gave up talking about Make years ago. There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools. I use one of the earliest Make versions that barely does…
Which version of make do you use? The one packaged in the 'heirloom' setup, or something different that's still available?
Re: Time for Makefiles to Make a Comeback
#47Earlier quoted context omitted.
You say the Pythonistas refused to use Gradle, but it also seems the JVM peeps refused to let go of it? Isn't that the problem? Isn't Make more general than Gradle? If the project was primarily JVM, why couldn't the Pythonistas be forced to use whatever build system was mandated?
You'd have to reinvent a lot of wheels to replicate what Gradle (or Maven) does. For example dependency management, env setup and packaging. It would be similar to asking a Python developer to give up pip, setup/disttools and maybe virtualenv. In the end you want productive devs. Stripping away the tools they are productive with is counterproductive.
But surely these are targets for make?
e.g a pip target that builds a python dep folder. You can do the same for Java with Apache Ivy.
Is Gradle not a make like system with a lot of JVM-specific functionality built in?
Re: Time for Makefiles to Make a Comeback
#48If you compare Makefiles to the JavaScript ecosystem it will do so favorably, but many things will. Make is a good build system but it is a shitty deployment system. Yes, you can do everything you want if you put enough effort in it as it is a complete scripting system, something many alternatives are not. It does not mean that it is a good idea to do so. Recently a client made me begrudgingly try Maven. 'Yet another…
That last bit is really key. Nearly every modern build system is also a dependency management system, something that really isn't possible using Make. There have been tools introduced to address that particular need for C/C++, but they integrate poorly if at all with the build system, so it turns all your builds into (at least initially) three step processes of run dependency installer, run config tool to figure out…
I think the declarative model is why I prefer Maven over any other build system I've worked with, yeah XML is a little noisy but if it's really that big of a deal there's the polyglot plugin. Maven POM's are pretty easy to figure out once you've worked with them for a while, there's a learning curve when you start adding plugins and have to get at least a basic understanding of build phases - but a large chunk of projects need nothing more than the default plugin bindings, they just add their dependencies and go off to the races.
Re: Time for Makefiles to Make a Comeback
#49I just got done watching a video called "make for reproducibility in science", which made a lot of sense. The impressio I get is people do weird things to make and then hit edge cases and complain.
> The impression I get is people do weird things to make and then hit edge cases and complain.
Like not handling file paths that have spaces? [0] That's one hell of an edge case.
Re: Time for Makefiles to Make a Comeback
#50Earlier quoted context omitted.
Make isn't intended to be used for dependency management. With traditional `./configure && make && make install`, dependencies are detected by the configure script, or manually provided by the user if they have custom library paths. Dependencies are handled by your package manager or something else (be it submodules in git, custom scripts, etc). There's a separation of concerns. For generating those configure files,…
Yes Make does one thing and one thing well. Having said that, if you really want to manage dependencies with Make, it's still trivial to do a curl/yum/rpm install when some component is missing. I've done that in the form of a `make deps` pseudo-target, to prevent doing anything that the user doesn't expect.
Yes having a separate target that isn't automatically invoked unexpectedly is important---the user doesn't expect network requests during build traditionally. Environments that build in isolation with no network access would fail as well.