Earlier quoted context omitted.
cmake is good but it is quite heavily geared towards C/C++ development. I would love to have some modern makefile with a bit nicer syntax. Fitting into 80 columns is no longer a must.
In case you didn't know, the 80 column limitation has its origins here https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_pun...
The Makefile I use with JavaScript projects
431–440 of 525 posts
Re: The Makefile I use with JavaScript projects
#432Re: The Makefile I use with JavaScript projects
#433Earlier quoted context omitted.
C is a systems programming language. It doesn't have closures or other features from functional programming. In other words, you can't "create functions at runtime". That is why you basically never see a function returning another function.
So, go is also a "systems" language, so the terms more or less meaningless now. Assuming you mean a language we can easily compile to an independent binary capable of being run directly on a microprocessor with no support, I offer you rust as a counter-example. Also, functional programming and returning functions does not mean they are created at runtime.
And "creating functions" means: closing over variables ("closures"), or partial application. I think it takes at least that to be able to return interesting functions.
(and whether go is a systems programming language is at least debatable. I think the creators have distanced themselves from that. It depends on your definition of "systems". You can't really write an OS in go).
Re: The Makefile I use with JavaScript projects
#434Make's interface is horrible. Significant tabs. Syntax which relies on bizarre punctuation... If only whoever authored Make 40 years ago had had the design acumen of a Ken Thompson or a Dennis Ritchie! We're stuck with Make because of network effects. I wish that it could just become "lost" forever and a different dependency-based-programming build tool could replace it... but that's just wishful thinking. The pace o…
Maybe I'm in the minority, but I've always found its syntax to be quite nice (though admittedly a departure from most modern languages). Then again, I find using JSON or not-quite-ruby to configure a build incredibly bizarre and confusing, so I guess I'm just set in my ways... In all seriousness, what's wrong with it? Significant tabs aren't great, but I feel like that's a relatively minor wart. The simple things are…
Not to push the particular product, but the approach:
FAKE (https://fake.build/), is an F# "Make" system that takes a fundamentally different tack to handling the complexity. Instead of having a new, restricted, purpose built language they've implemented a build DSL in F# scripts.
That yields build scripts that are strongly typed, just-in-time compiled, have full access to the .Net ecosystem and all your own code libraries, and are implemented in a first class functional language. That is to say: you can bring the full force of programming and abstraction to handle arbitrarily complex situations using the same competencies that one uses for coding.
As the build file grows in complexity and scope it can be refactored, and use functionality integrated into your infrastructure code, in the same way programs are refactored and improved to make them manageable. The result is something highly accessible, supportive, and aggressively positioned for modern build chains... If you can do it in .Net, you can do it in FAKE.
Re: The Makefile I use with JavaScript projects
#435Earlier quoted context omitted.
Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly why he's fixated on the GUI... But I had forgotten, computers aren't useful as tools to accomplish work, but as mechanisms to assuage intellectual inferiority complexes. He should advocate for punch cards again, since that would certainly stop morons from using computers.
Window and Linux shells have the same ideas about spaces in file names, which is that if they appear they need to be quoted or the space character needs to be escaped. Outside of Make which has long and boring historical reasons for not supporting spaces well, just about every program is fine with spaces.
Re: The Makefile I use with JavaScript projects
#436Earlier quoted context omitted.
Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches. I hate hearing people using 21st century or modern as…
The fact that Unix tools have trouble with spaces in filenames is absolutely a problem with Unix. If the Unix ecosystem had better support for this, then it wouldn't be a problem.
Re: The Makefile I use with JavaScript projects
#437Earlier quoted context omitted.
Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches. I hate hearing people using 21st century or modern as…
> And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Users expect computers to work in a non-surprising ways. It isn't natural to use dashes or underscore in file names. Training users to be afraid of spaces is just teaching them one…
Re: The Makefile I use with JavaScript projects
#438Earlier quoted context omitted.
> And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Users expect computers to work in a non-surprising ways. It isn't natural to use dashes or underscore in file names. Training users to be afraid of spaces is just teaching them one…
> Users expect computers to work in a non-surprising ways. "Users" is a very broad category with a bunch of partitioning. The particular subgroup in question are authors of build automation systems for medium to large scale software projects. They (we) have a rather different perspective on "surprising".
For desktop software, a build automation system needs to handle files that are included in the installer, installed on user’s machines, and in some cases be discoverable by end users of the software.
I would be very surprised if my build system wouldn’t support spaces in file names.
Re: The Makefile I use with JavaScript projects
#439I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for use by humans. Since this is the 21st century, those files have spaces in their names. At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. A little searching reveals that the consensus on usi…
Spaces in filenames create troubles with almost every command line tool. cut(1), awk(1), find(1), xargs(1), what not. How do you quote them, do you need to use \0 as a separator instead, do other commands on the pipeline support \0 separators? What happens after a couple expansions, passing stuff from one script to another? And what the heck happened on 31 dec 1999 that the world became a different place where sudden…
Then that's a shortcoming which should be addressed with the tools, because humans everywhere use spaces in filenames.
For every command-line tool I make (Windows & Linux), I ensure it handles such trivial use-cases. I can't see why such a simple task is seemingly impossible to get done in GNU coreutils.
Re: The Makefile I use with JavaScript projects
#440Earlier quoted context omitted.
What's your solution for mutliple-output processes like yacc/bison (which creates both an .h and a .c file?)
I don't run into those too often. When I do, there are two cases: 1) All dependencies are on only one output file (e.g. link stages that generate .map files, compile phases that generate separate .o and debug files). I just treat these as normal 2) I may need to depend on each of the files (I don't use yacc/bison, but it sounds like this would qualify). I select one file to be the main output and have the .do file fo…
I once solved it by making a tar file or all the outputs and extracting it to both .c and .h but that’s incredibly kludgy, still looking for a better solution