| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Just ran into first issue from using the portable /bin/sh rather than a
modern shell:
https://stackoverflow.com/questions/15744421/read-command-doesnt-wait-for-input
Turn on errexit everywhere.
|
| | |
|
| | |
|
| |
|
|
| |
Don't run Mu if the compile fails.
|
| |
|
|
|
|
|
|
|
| |
A generic build system is overkill for such a small project, and it was
adding complexity on OpenBSD which doesn't come with GNU make by
default.
In the process we also eliminate our reliance on bash and perl, at least
for the core build script.
|
| |
|
|
|
|
|
|
| |
Support for a minimal OpenBSD without bash. Many of the scripts in the
repo won't work in that situation, but let's at least make the `mu`
script work.
I'd like to come up with a clean makefile that doesn't require GNU make.
|
| |
|
|
|
|
|
|
|
|
| |
Now that we have a new build system we shouldn't need to run unoptimized
just to save time. (Though that's not strictly true; if a change
modifies .build/mu_0.cc which is twice as large as later compilation
units, dropping -O3 shaves 10s off the time for an incremental build.)
Since we don't need to run unoptimized anymore, let's just explicitly
ask for --test-only-app when we need it.
|
| | |
|
| |
|
|
| |
Follow convention more closely by using CXXFLAGS for C++ files.
|
| |
|
|
|
|
|
|
| |
The mu commandline now has four parts: options, commands (of which we
only have one so far: 'test'), files/directories and ingredients to pass
to 'main'. That cleans up the hacky ordering constraint we had earlier.
I've also cleaned up the usage message.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Complicated logic to not run core tests. I only want to disable core
tests if:
a) I'm changing CFLAGS on the commandline (usually to disable
optimizations, causing tests to run slower in a debug cycle)
b) I'm not printing a help message (either with just 'mu' or
'mu --help')
c) I'm loading other files besides just the core.
Under these circumstances I only want to run tests in the files
explicitly loaded at the commandline.
This is all pretty hairy, in spite of my attempts to document it in
four different places. I might end up taking it all out the first time I
need to run core tests under all these conditions.
|
| | |
|
| | |
|
| |
|
|
| |
I've tried to update the Readme, but there are at least a couple of issues.
|
| |
|
|
|
| |
Still klunky since mu has no notion of a return value. I find myself
using $print all the time.
|
| | |
|
|
|
When I'm doing extensive surgery to the internals I want to avoid
loading higher levels; they aren't expected to work. But I don't want to
keep different levels in separate files just for that. And I definitely
don't want to put low-level stuff first. Now I can influence loading in
a cross-cutting manner by creating sections with numbers:
(section 100
...code...)
And disabling them by running:
$ ./anarki/arc 99 mu.arc.t
Currently we load all mu 'system software' in level 100, so running at
level 99 sidesteps them. Lower levels coming soon.
But most of the time we don't need to worry about levels, and the 'mu'
script lets us forget about them. Just run .mu files with:
$ ./mu factorial.mu
To run tests:
$ ./mu test mu.arc.t
|