lolikoisuru

>Make has a fragile syntax that barely works for simple filenames

It works perfectly fine with things other than space.

>and it has a host of cryptic functions with difficult to understand semantics

This is why the GNU Make has a fantastic manual, I suggest you check it out: https://gnu.org/s/make/manual

>That it's what is installed on most Unix-style computers isn't an argument against trying to make different/better systems.

You aren't making a better system though. You're making a worse, less flexible, less understood, system that no one can hire person to work for and that won't be useful at any workplace. If you really wanted to improve over make you'd be making a general purpose tool that isn't targeting any specific project or language.

Alas, this has jack shit to do with the comment you're replying to. Let's deal with the issues we've been talking about before shifting the goalpost.

>Also, you can set SHELL to another scripting language, but that defeats much of the point of using make in the first place.

It still gives you a standard interface that packagers and users would expect for build software and you don't have to rewrite your DAG every time by hand.

>And again, you still need to spawn processes and transfer state through a fragile text interface.

You break the task into multiple parts so you hopefully don't have to run it all every time. Text files aren't really any more fragile than any other way to tranfer the state, just write a json or whatever format you like.

>And most languages' syntaxes integrate even worse with Make's than sh does.

What integration do you want that you had in your silly hand written one?

>How do I insert commas between words to generate python lists would be my first question, and frankly I do not want to know the answer.

You can either construct a macro to do this or you can just give the data space delimited to python and change the spaces to commas there. Surely you know how to do it with python so why are you insisting on doing it with make?

>It's not true that it's impossible to design a system that was better than Make.

Of course it's possible. Too bad no one has actually attempted it.

>And the "compatibility" argument is just not there, sorry. Yes, I require python, but that's it. I wrote a simple script that just runs and build. Nothing wrong with that.

You also require your own library. Most people probably don't have this installed. Also if you wrote this at a company and left then they'd have a half-baked build system and they cannot hire anyone that's familiar with it.

>I mean that you have to start a new process, and hand over all state as command-line parameters (because it's a new process).

Do you mean to the shell's command-line parameters or the compiler's? Either way whatever state you need you can also give as macro expansions.

  MACRO := whatever
  SHELL := /usr/bin/python
  .RECIPEPREFIX := >
  
  .ONESHELL:
  .PHONY: all
  .SILENT:
  
  all:
  >foo="$(MACRO)"
  >print("{}".format(foo))
  >print("You can call yur compiler from python if you want. You could even write the build system from OP here if you wanted to")

>This can be impractical and error-prone, especially if you add shell AND make syntax on top.

Make syntax is just simple macro expansion. Shouldn't be too hard. And no one is forcing you to use a bourne-style shell. You can use Lua, Perl, Python, Javascript, whatever you want.

>From within a decent scripting language (e.g. Python) instead

You can use Python.

>you can simply use the convenient built-in data structures (e.g. list/tuple of str) as command-line parameters for subprocesses.

Then do that here. You don't need to reinvent everything just because you dislike one part of an existing solution. This kind of NIH is why there are so many sub par solutions for everything and nothing is compatible with each other.

>Replace "having start" with "having to start". And maybe replace "solve" with "remove", which might be a better fit here (I'm not a native speaker).

The latter half of the sentence is still incomprehensible.

>which I considered inappropriate

You never specified what about it is inappropriate. Your complaints about the language amounted at most to a pathetic ad hominem.

>As a result you replied in a way that missed any understanding and respect

There was nothing to understand as you had not communicated anything but the fact you found it somehow offensive. As the comment contains nothing offensive you need to be more specific. Since you didn't do that it comes of just as a dismissive personal attack.

>and harshly critized me for writing in an unintelligible way

This is because the sentence was unintelligible even when I'd asked multiple people to try to interpret it. This is not harsh criticism, it's just a statement of a fact.

>(I accidentally left out one word in a sentence, sorry for that)

The lack of that word made the sentence completely nonsensical. Why are you whining to me about not understanding it? And it seems you never fixed the sentence so it's still just as unintelligible.

>Changing SHELL does not solve the inconvenience of having start a new process and having to go through a command-line interface each time.

What does this mean?

>Your borderline personal attacks (one of which was apparently removed

Bitch please. You're the one who started with those.

Then what was the point of your comment to begin with?

Is the codebase you're trying to compile available somewhere?

>I very much doubt that torrent client authors consider this to be a vulnerability in their client

How could anyone not consider this a vulnerability when it has an actual CVE assigned to it?

The discussion in the github issue also shows they took it pretty seriously: https://github.com/transmission/transmission/pull/468

I would like to attempt this even though I'm not the person you're replying to.

There is just one problem though, your page isn't loading.

>It just wasn't a fully fledged turing complete programming language

It is turing complete though.

What browser do you use that can't play webm?

It's out of scope for any general purpose DAG runner. Sure you can make a tool that can do that for language X, but make is used with a lot more than that. Make should not implement parsing of source code to find out what they include.

>You mean the one build system that doesn't know the first thing about header files?

It's a general purpose DAG runner. It's not really feasible to add parsing for all the different possible languages that one might want to use imports in. Luckily at least GCC and Clang both have the option -MMD and any sane compiler for other languages should have something similiar.

> Make's approach appears to be to use cryptic flags and settings

You already memorize similiar syntax things for other languages. Why is it so hard to accept in this case? Comparatively there are a lot less of them to remember with make as well. Stop being lazy and read the manual.

> and the best case documentation appears to be "have you tried stack overflow?".

Make's documentation is fantastic. The manual is very comprehensive and well written. Just because you're too lazy to read a manual doesn't mean there isn't documentation.

Go read the documentation for make: https://gnu.org/s/make/manual/

>If it's about making it easy for uninitiated collaborators to add new source files, then the listed build description format is pretty self-explanatory to use.

If you write a generic makefile the uninitiated collaborator doesn't have to do anything to add new source files.

This is pretty good explanation.

https://media.8ch.net/file_dl/25ece2fb253fc4e6cdd3ac4ed99e4f...

>What about: cross compilation? ccache injection? verbose builds? parallelism control? installation prefix? Try being a package maintainer for a GNU/Linux distribution, where all of the above needs to be kept under control. You will despise custom build systems.

None of those are features that developers care about. They are only of interest to package maintainers, systems administrators and other lunatics.

>its configuration syntax is awkward

This argument and others similar to it are often repeated but I've yet to see any of those people describe what makes it awkward.

>and it is restricted to filesystem files and shell commands

It'd be pretty easy to make a makefile that depends on say a specific row on a SQL database using dummy files. Also changing the language for recipes is trivial and painfully obvious. If you can't do something as simple as `SHELL := /your/own/interpreter' then why do you think you are qualified to make a build system?

And with that goes any chance of me ever even trying slack.

If I were to write a makefile for something where I can't restrict the filenames beforehand I'd probably just have a target for running `detox` and then at the very end possibly an another target that changes underscores to spaces and creates some dummy file as the real target.

If you’re feeling mischievous, Make has divers ‘secret’ vars & targets for you. For instance, you don’t have to ‘struggle’ w/ the ancient bash, for it’s possible to program recipes in any language that supports evaluations straight from the command line.

In addition you can have different shell for each rule with the rule specific macros if you do desire:

.ONESHELL:

.SILENT:

.PHONY: rule1

rule1: SHELL := /usr/bin/python3

rule1:

     foo=bar

     print("python: {}".format(foo))

One thing I sometimes wish was possible in make is using the automatic variables in the dependency part of the rules. The one that I most often have desired to use is $(@D) so I could depend on a file with specific name in the same directory when the directory name isn't known beforehand. I got around this with some touch trickery but it would be just easier to read if those automatic variables were available at that point.

>When in doubt, don’t google until you read the official manual. It’s a document of an astonishing quality. Go print the pdf.

This applies to most GNU software.

I won't because I'll be dead.

No. They can't.

None of these work without binary blobs.

Here is my embarassing personal website from the 2010s: https://gnu.moe/

LWN.net

It's not a blog or a newsletter but proper journalism and definitely worth the $5/mo I pay for it. I don't think there is any newsletter that just recycles other people's content would be worth the money.

Python might not be rare but Meson for sure is. Cmake and autotools are very common compared to that.

> I could somehow shove a C preprocessor into it and make it automatically generate dependencies based on include directives.

But the C compilers already provide tools for example `gcc -MMD`