Commit Graph

20 Commits

Author SHA1 Message Date
Kartik K. Agaram 075498ec16 4220 2018-03-13 08:37:19 -07:00
Kartik K. Agaram c912b7319f 4219 - add an even simpler build script 2018-03-13 08:34:05 -07:00
Kartik K. Agaram f0cf7af7d8 4216 - include simpler alternative to build script 2018-03-12 23:26:10 -07:00
Kartik K. Agaram ba838feae9 4211
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.
2018-02-20 01:38:15 -08:00
Kartik K. Agaram b53ee143f8 4015 2017-10-11 01:47:00 -07:00
Kartik K. Agaram 9a81d7460f 3561 2016-10-22 16:56:07 -07:00
Kartik K. Agaram a362c95c68 3468
Don't run Mu if the compile fails.
2016-10-07 13:52:56 -07:00
Kartik K. Agaram a232af2faf 3447 - drop dependence on GNU make
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.
2016-10-06 15:40:56 -07:00
Kartik K. Agaram 1593590296 3442
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.
2016-10-05 22:41:59 -07:00
Kartik K. Agaram 0708d07f90 3287 - drop hacky implicit meaning of CXXFLAGS
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.
2016-08-31 13:19:16 -07:00
Kartik K. Agaram b856e7e15f 3276 2016-08-28 23:59:07 -07:00
Kartik K. Agaram c5d5431990 3275
Follow convention more closely by using CXXFLAGS for C++ files.
2016-08-28 23:52:07 -07:00
Kartik K. Agaram 78e3f55368 3170 - multiple --options at the commandline
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.
2016-08-12 15:53:48 -07:00
Kartik K. Agaram 60e11efcb0 3137
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.
2016-07-22 23:36:19 -07:00
Kartik K. Agaram 395e2128a4 2994 2016-05-21 10:59:28 -07:00
Kartik K. Agaram fa3d7edce4 1706 - automatically recompile mu when necessary 2015-07-04 20:53:26 -07:00
Kartik K. Agaram b96af395b9 1276 - make C++ version the default
I've tried to update the Readme, but there are at least a couple of issues.
2015-05-05 21:17:24 -07:00
Kartik K. Agaram eacb2ce458 828 - interactive repl
Still klunky since mu has no notion of a return value. I find myself
using $print all the time.
2015-02-23 00:45:35 -08:00
Kartik K. Agaram cb7b0f84fe 407 2014-12-13 00:51:32 -08:00
Kartik K. Agaram 4f9f75ddcf 405 - permit loading just low levels of codebase
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
2014-12-13 00:40:01 -08:00