| Age | Commit message (Collapse) | Author |
|---|
|
This represents quite a few evenings of hacking. It doesn't build all of my
Python code, because my Python code is not up to snuff, but it builds the
examples and pulls in third party dependencies.
Some design points:
- I'm using buildPythonApplication in Builder.nix because it was getting way too
annoying to wrap the Python script and set PYTHONPATH myself. Easier and more
robust to just use the upstream nix builder
- Because of this, I had to generate a setup.py. Maybe switch to pyproject.toml
in the future, whatever.
- Also because of this, Target.wrapper is becoming redundant. I'll just remove
it when I get Guile built in nix.
- Biz/Bild.nix is getting messy and could use a refactor.
- In Builder.nix, I worked around the empty directories bug by just finding and
deleting empty directories after unpacking. If its stupid but works it ain't
stupid!
- I had to touch __init__.py files in all directories before building. Annoying!
- `repl` just works, which is awesome
- To ensure good Python code, I moved lints and added type checking to the
build. So I can't build anything unless it passes those checks. This seems
restrictive, but if I want to run some non-passing code, I can still use
`repl`, so it's actually not inhibitory.
|
|
|
|
This is prototype quality. For some reason I think it breaks when doing
`build **/*.hs`, which isn't good. But also it's working, and the code feels
good. Next I'd like to get Python builds working, as hopefully that will force
me to improve the existing code to support a second language.
|
|
There are some limitations to this implementation:
1. Using `runCommand` means this will re-run any time anything changes in the
repo. The solution is to use the existing import detection to make a list of
source files, and put that into a `stdenv.mkDerivation`, which I'll do next.
2. The `NeatInterpolation` usage is ugly. The templated nix code should be
extracted into its own file, such as `Biz/Bild/Builder.nix`.
3. I'm not actually calling it yet. The ideal thing would be to call
`nix-instantiate`, get the output drv path, and then call `nix-store --realise`
on that. To do that I need to refactor my `proc` function to return stdout to
the calling function, and I should probably just make helper functions like
`nixInstatiate :: Target -> IO DrvPath` and `nixStoreRealise :: DrvPath ->
NixStorePath`, or something like that.
|
|
|
|
|
|
Without this, Guile libraries like SDL2 will use Guile 2.0 instead.
|
|
At least one namespace (Biz/Dragons/Analysis.nix) needs this.
|
|
|
|
Mostly thid required packaging up some deps, but also had to recompile
stuff with cuda support.
|
|
|
|
|
|
As a byproduct this also (sorta) generalizes how I pass flags to the C compiler
using pkg-config, instead of using the guile-config. Now the 'lib' metadata will
be added with 'pkg-config --libs', and the 'sys' metadata will be added with
'pkg-config --cflags'. I'm not *really* sure what the difference is, but if it
works it works.
|
|
|
|
Unfortunately, until bild can instantiate nix builds, it needs all of its
compilers in the dev environment, and I need to pass this environment into the
dev nix-shell in order for it to work in the repl or after being built to _/bin.
|
|
|
|
In order to write Guile code against C, I need to distiguish between libs and
bins, so I did that, then I got the flags that gcc needs from `guile-config` and
put them in the args for any C lib build. I tested this with Bessel.c and
Bessel.scm (not in this patch, because I don't really want that code in my
tree, I'll come up with another way to test it later).
|
|
|
|
|
|
|
|
Rust seems to not be supported in my ctags version :(
Also rename some Ide scripts because these are commands, not really scripts.
|
|
|
|
I don't care about ghcjs anymore, the most javascript I want to do is jQuery.
|
|
|
|
I had thought that I needed some unmerged commits to nixpkgs that enable Guile
3.0, but turns out I just needed to use a different target name :P
|
|
asdf seems to always be necessary for any other packages to work, so I just
include that in the call to nix-shell, and swank is included because it's just
useful to start a repl server.
|
|
I ended up deleting miso, and consequently all files under Hero/ and Miso/,
because I couldn't get miso to build with GHC 9.2.
Other things:
- Niv has been wrapped by Biz/Bild/Deps.hs, so I can extend it to my liking.
- Apply-refact is gone because I couldn't get it to build.
- Disabled python stuff.
|
|
This way I can still inspect and use them from the nix repl by just doing `:l
Biz/Bild.nix`, but its also clear that they aren't part of the normal build
rules.
|
|
|
|
|
|
Support for packages and third-party imports will need to come later once I
figure out how to lookup rust packages by their import statements. Until then,
this works to compile "hello world".
|
|
|
|
This is basically building on top of bild's analysis, which is great becuase it
means that bild is becoming a useful tool rather than a monolithic do-everything
job runner. The eventual goal is for the bild analysis to be much more useful,
maybe even provide data to remote repls or language-server or whatever.
|
|
|
|
This means my call to ghc-pkg will look at the full package set from Hoogle.
|
|
|
|
|
|
|
|
This also makes some changes to the build tooling to clean up the environment a
bit, and get us closer to 'bild -s'.
|
|
This parses the files contents for imports, then uses ghc-pkg to lookup the
package that provides the module. Now I can do that analysis in Haskell instead
of nix, which is much easier to code with.
|
|
|
|
|
|
Getting me closer to the latest GHC. This release also includes my own packages
that I submitted some time ago.
GHCJS is not present in 21.05 for some reason, but I think it's back in master,
so I might do another upgrade soon, but for now I just disabled my GHCJS
support. I'm not really using it anyway.
I also had to bring it string-quote, update nixos-mailserver, and a few other
things.
|
|
|
