[okaleniuk]

I love things like these because they shake our perception of normal loose. And who said our perception of normal doesn't deserve a good shake?

A C to shell compiler might seem impractical, but you know what is even more impractical? Having a separate language for a build system. And yet, here we are. Using Shell, Make or CMake to build a C program is only acceptable because is has always been so. It's a "perceived normality" in the C world.

There is no good reason, however, CMake isn't a C library. With build system being a library, we could write, read, and, most importantly, debug build scripts just like any other part of the buildable. We already have includeOS, why not includeMake?

[eichin]

DSLs ("microlanguages", at the time) were a big idea in the late 80s - by being expressive in ways closer to the problem, they could leave out irrelevant things and the bugs they lead to. (Do you really want to have to explicitly call malloc() in your build tools? and does gdb really feel like the right tool for debugging one?)

[lmm]

> Using Shell, Make or CMake to build a C program is only acceptable because is has always been so.

Nah, using shell, make or cmake is acceptable because C is obviously a terrible language for doing things. (Those languages are also all terrible, but not quite as terrible as C).

> There is no good reason, however, CMake isn't a C library.

Isn't it the other way round? There's no good reason people write programs in C rather than CMake.

> With build system being a library, we could write, read, and, most importantly, debug build scripts just like any other part of the buildable.

Which is to say, with extreme difficulty?

Like, I agree with where you're coming from, it is absolutely a damning indictment of C that people don't want to express their builds in it. But writing in a build in C really would be terrible.

[okaleniuk]

I think you're confusing the language and the perception of language, the "rules of C" vs. the "brand of C".

What Pnut shows us is that the language itself is a very thin construct. C could be as low-level as you want, but it can also... compile to shell. Pnut shows that C is only a set of grammatical rules, and the source code in C doesn't necessary reflect the binary program, it's only a script for the C compiler. A compiler then decides how to interpret the source and what to do with it.

Now back to builds. The difference between:

    set(SOME_VARIABLE "SOME VALUE")

and

    set(SOME_VARIABLE, "SOME VALUE");

is purely grammatical. The underlying functionality is the same. When I'm saying, CMake could be a C library, I'm not saying we should ditch CMake and everything it brings to the table and start writing build scripts in pure C. I'm saying we can use both C language and CMake functionality with very little, skin deep, adjustments.

The only thing that keeps us down is the perception of C as a low-level language for low-level applications. C is for drivers and shell is for moving files around. And that's when Pnut comes up and tells us: "hold on, are they?"

[lmm]

> The difference between: > set(SOME_VARIABLE "SOME VALUE") > and > set(SOME_VARIABLE, "SOME VALUE"); > is purely grammatical. The underlying functionality is the same.

But in a build script you don't want to be doing either. You want SOME_VARIABLE = SOME VALUE, or at most "SOME VALUE". Grammar and syntax matter.

> Pnut shows that C is only a set of grammatical rules, and the source code in C doesn't necessary reflect the binary program, it's only a script for the C compiler.

The only thing worse than writing C is writing something that looks like C but doesn't follow the rules of C, where you have to use some other logic to understand what it actually does. Build tools that do that kind of thing have been tried and they have not turned out well.

> When I'm saying, CMake could be a C library, I'm not saying we should ditch CMake and everything it brings to the table and start writing build scripts in pure C. I'm saying we can use both C language and CMake functionality with very little, skin deep, adjustments.

"Skin deep" perhaps, but making your language uglier and weirder is still unpleasant (and CMake is unpleasant and weird enough as it is).

> The only thing that keeps us down is the perception of C as a low-level language for low-level applications.

No, the other thing is the perception of C as a crude, inexpressive language full of weird edge cases that requires dozens of lines to write even simple things, and that in turn comes from the reality of C as a crude, inexpressive language full of weird edge cases that requires dozens of lines to write even simple things.

[okaleniuk]

If syntax mattered that much, CMake would have opted for SOME VARIABLE = SOME VALUE. But... they went for set(SOME_VARIABLE "SOME VALUE") instead. I don't know why.

Syntax-wise C is fine. I personally have a soft spot for Rebol's "syntax free" approach, but the world prefers C. Five out of ten TIOBE's most popular languages have C-like syntax.

And you're right that the perception of C comes from the usage of C. Of course it does. But this creates the vicious cycle, the cycle things like Pnut are trying to break.

[lmm]

> the world prefers C. Five out of ten TIOBE's most popular languages have C-like syntax.

I don't know which five you're classifying that way, but even for languages that started off C-like the trend is in the direction of less C-like. Even for C++ the big popular changes recently have been things like auto; similarly for Java, and C# always had a more lightweight syntax for expressing values. And certainly JavaScript has an object literal syntax good enough that people use it separately. Python is admittedly weirdly bad for writing values in; I wonder if that's why Scons has more or less failed.

[bregma]

Why would you need a screwdriver or a glass cutter if you already have a hammer?

[okaleniuk]

With C, you have the whole toolbox and the toolbox factory.

[defrost]

Both the tweezers and the bit flipping magnet .. and who would want anything more?

[thechao]

Yeah — C would be ok as a build system language if it was easy to: invoke & manage subprocesses; build & manage dynamic dependency graphs; and, easily work with file metadata.

Or... work with me: Make does that, well enough.

[okaleniuk]

And that's why I'm saying CMake should have been a library. We want the functionality of Make but not necessary the language. And Pnut shows us well that {language != functionality}.

For the sake of mental experiment, let's pretend Make is a separate executable, separate process, but with some sort of API. You can manage dynamic dependency graphs by calling its routines from C.

Now let's say Make is a dynamic library with all functionality exposed. You can invoke and manage subprocesses using its functions, but now your C program and the Make share a process together.

Now let's say Make is a C library. GNU Make is written in C so this is not impossible to imagine. Your C program shares the process, and the names on compilation+linking phase with Make, which is annoying. But you can still work with metadata using Make's facilities. Also now you can use all the tools: debuggers, profilers, static analyzers, dynamic analyzers - you use for the rest of your codebase.

We perceive C as a low-level language but, and Pnut shows it well, C is only a set of rules. We can write shell scripts with C rules. Why can't we then write build scripts?

[evilotto]

> So we stopped selling those [hammer factory] schematics and started selling hammer-factory-building factories.

https://web.archive.org/web/20180722051250/http://discuss.jo...

[skinner927]

Have you tried Zig? Its build system is configured in the language. It’s actually a binary you build and run to build your project. Obviously the standard library has facilities for making building easy.

[jcelerier]

> but you know what is even more impractical? Having a separate language for a build system.

I disagree. For a very simple example it really makes life easier to not have to care about quoting filenames in build systems and just list a.c b.cpp etc., while you really want strings to be quoted in normal programming languages. Build systems that tried to be based on syntax of existing PLs (for instance Meson, QBS) are a real PITA for me when compared to CMake due to a lot of such affordances.

[RHSeeger]

> you know what is even more impractical? Having a separate language for a build system

Why is it you think that?

[bitwize]

Terry Davis was right. C should be your shell, as God intended.