Built-in recipe handler/make replacement

[kyle]

I have read the point about having the compiler handle dependency resolution etc. so that there are fewer tools. 

I would like to point out that Java started that way.  Javac will go find included packages and compile the code if necessary.  However, in practice, this proved to be insufficient and now I almost always see Ant, Maven, or other build systems used instead.  I am not sure of all the reasoning behind this, but I can think of a few things:

0) it never really worked for more than very simple things. 

1) if there is any code generation going on (think yacc), then javac could not handle it.

2) going outside java for some artifacts did not work.  I.e when building a WAR file, you need all the crufty XML, images, static HTML etc. etc. as well as the .jar and/or .class files.

3) NIH syndrome.  Why else would we have make, cmake, scons, etc. etc. etc. etc. etc.

4) changes and additions to the build system required a release of the whole compiler.

I think go does most of the work for compiling Go code.  So, there is some backlash against separate tools.

I am not saying that combining the build system into one tool with the compiler is wrong, but there are some tradeoffs that should be thought about.

One example I really like is git.  The core git code (the plumbing) is a small set of tightly linked programs (they were in shell, now mostly C I think).  On top of that is the "porcelain" that provides varied and higher-level interfaces.   Go is much this way too, I believe. 

The caveat to all this is how does a different executable know how to link together various modules to run a program?  C has several steps to get to an executable.  The linker step is not part of the compiler (conceptually).  In C2 it is.  Modules make this a little trickier.  Certainly the pain of keeping Makefiles up to date is something to be avoided!

How can C2 keep that simplicity but avoid the problems that Java, for instance, ran into?

Best,
Kyle

[bas]

Good points!

For most C++ project I currently work on, we use either CMake or qmake (Qt).
These behave at a level of a C2 recipe. I think we can avoid most of the Java case,
since in C2 there will be certain hooks for (Yacc) generated files etc. I'm even
thinking of integrating lua here. So that way a developer can run scripts at
certain points. That should be enough for 99.9% of the cases. The weird 0.1% will
have to use make and Plain old C

But you make a good point. The best argument I have for integrating a build system
is that for C there are Soo many build systems, that something must be missing.
Additionally forcing developers into a common way (a bit like Python), is something
C developers are not used to, but does yield significant speedup is development time.

[kyle]

Tooling is a big factor in languages.  That is something that I think C2 is doing correctly.  Modules, in particular, are important for that.

Take, for instance, Typescript.  Though I am not a fan of Microsoft (in spite of living within 10km of Microsoft HQ), I think they did a really good job on Typescript.  It has just enough information for tooling (IDE, compiler etc.) to give useful feedback to the programmer.

Java tried to do something about this with the .class files containing enough information to find the dependencies at runtime.  Unfortunately, their scope was too small and they only included code.

Eclipse handles dependencies in the environment via a blizzard of XML files.  Ant and Maven use XML too.  I am not a fan of XML.  "Human" readable? 

I think there is a corollary to Greenspun's Tenth Rule here :-)  Any sufficiently complicated compiler system ends up (badly) implementing part of make :-)

One of the use cases that hits me with some regularity is using Make to do builds for multiple platforms.  I have code that needs to run on Windows and Linux. 

Rather than get bogged down in guessing what a build system needs, how about some larger projects in C2 to find out what would be useful?    Maybe a small web server or something?

I have some small macros that I use heavily in C code, but they evolved over a couple years of use to the point they are now.  I am still working on my resource alloc/dealloc idea though.  If I can get that one, I'll be able to unify a lot of the things I was doing.

Best,
Kyle

[bas]

I'm not familiar with TypeScript, but am a fan of doing a larger project in C2 to see which
issues we run into. I currently write down all the (minor) issues I run into when programming
C and then try to think of a better solution. A lot of these solutions can already be found in the
D programming language. They have some really cool ideas, their macro-replacements for
example.

Because implementing the IR generator to interface with LLVM is taking so much time, I
have changed my focus on the C generation first. That is a lot easier and then the project
becomes usable for programmers who want to use/try the language. To still show some
powerful features, I'm also working on c2reto, the C2 REfactor TOol. 
This tool should be able to do global renames, drag'n drop reordering (even across files)
of functions,types and globals, etc.

[kyle]

Typescript is a dialect of Javascript by Microsoft.  Before you think "Ah, embrace and extend!", it is not that.  Microsoft wrote the compiler (transpiler) in Javascript.  It runs in Node.  They did put a lot of tooling into VisualStudio.  Apart from the VS extensions, the whole thing is open source.  It is a nice approach of adding just a little bit to Javascript (Javascript is valid Typescript) while maintaining full backward compatibility.  Since they don't own the browser market anymore, they'd better play nice with the browsers :-)

I am looking forward to hearing more about c2reto!  Sounds very interesting!

Before I make any more comments, I want to make sure that it is clear: I think the work you are doing on C2 is amazing and great!  It is easy to sit on the side lines and make comments, but you are actually writing code.

Best,
Kyle

[bas]

I must have missed these (the forum doesn't show new messages at top level somehow).

Yes writing takes a lot of time, but is also a lot of fun.
I will look into your SPECS and cbang posts, always nice to see similar thoughts!
When studying Apple's Swift recently, I was amazed how much similarity there is
between modern languages. Almost all use 'import' and 'module' for one thing.

Cheers,
Bas