julec: init at 0.1.3

[koibtw]

Jule is a general-purpose programming language focusing on systems programming. It aims to be fast, efficient and safe. Jule has its own set of goals and ideas that make it original.
Website: jule.dev

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[ethancedwards8]

Also, everything probably needs to be in by-name instead. Also, you probably want to split the two packages into their own files.

[koibtw]

@ethancedwards8 Suggestions applied.
There is one package. The IR codes are necessary for building JuleC.

Also, everything probably needs to be in by-name instead.

What about development/compilers?

[ethancedwards8]

@ethancedwards8 Suggestions applied. There is one package. The IR codes are necessary for building JuleC.

Also, everything probably needs to be in by-name instead.

What about development/compilers?

Not sure. good question. Probably best to leave it for someone more experienced than me to comment

[koibtw]

Suggestions applied. I've moved the package to development/compilers.

[koibtw]

@ethancedwards8 @wegank conflicts resolved

[philiptaron]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 379891

---

x86_64-linux

✅ 1 package built:

• julec

[philiptaron]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 379891

---

x86_64-darwin

✅ 1 package built:

• julec

[FliegendeWurst]

Would suggest to change as below.

1. abort should not be used, as it cannot be caught
2. instead of specifying clang++, make the derivation work for other compilers too (use (julec.override { stdenv = clangStdenv; }) to get a clang-compiled version)
3. correct platform list based on the if statement at the start
4. other best practices

diff --git a/pkgs/by-name/ju/julec/package.nix b/pkgs/by-name/ju/julec/package.nix
index 50007c3a5f97..68457a72960a 100644
--- a/pkgs/by-name/ju/julec/package.nix
+++ b/pkgs/by-name/ju/julec/package.nix
@@ -2,7 +2,6 @@
   lib,
   stdenv,
   fetchFromGitHub,
-  clang,
 }:
 
 let
@@ -18,7 +17,7 @@ let
     else if stdenv.hostPlatform.system == "aarch64-darwin" then
       "darwin-arm64.cpp"
     else
-      abort "Unsupported platform: ${stdenv.hostPlatform.system}";
+      throw "Unsupported platform: ${stdenv.hostPlatform.system}";
 in
 stdenv.mkDerivation (finalAttrs: {
   pname = "julec";
@@ -35,13 +34,13 @@ stdenv.mkDerivation (finalAttrs: {
   irSrc = fetchFromGitHub {
     owner = "julelang";
     repo = "julec-ir";
+    # revision determined by: ?
     rev = "a274782922e4275c4a036d63acffd3369dbc382f";
     name = "jule-ir-${finalAttrs.version}";
     hash = "sha256-TXMSXTGTzZntPUhT6QTmn3nD2k855ZoAW9aQWyhrE8s=";
   };
 
   dontConfigure = true;
-  buildInputs = [ clang ];
 
   unpackPhase = ''
     runHook preUnpack
@@ -61,14 +60,14 @@ stdenv.mkDerivation (finalAttrs: {
 
     echo "Building ${finalAttrs.pname} v${finalAttrs.version} for ${stdenv.hostPlatform.system}..."
     mkdir -p bin
-    clang++ ir.cpp \
+    ${stdenv.cc.targetPrefix}c++ ir.cpp \
       --std=c++17 \
       -Wno-everything \
       -O3 \
       -flto \
       -DNDEBUG \
       -fomit-frame-pointer \
-      -o "bin/${finalAttrs.pname}"
+      -o "bin/${finalAttrs.meta.mainProgram}"
 
     runHook postBuild
   '';
@@ -81,13 +80,13 @@ stdenv.mkDerivation (finalAttrs: {
     cp -R api $out/lib/jule/api
     cp -R std $out/lib/jule/std
     cp -R bin $out/lib/jule/bin
-    ln -s $out/lib/jule/bin/${finalAttrs.pname} $out/bin/${finalAttrs.pname}
+    ln -s $out/lib/jule/bin/${finalAttrs.meta.mainProgram} $out/bin/${finalAttrs.meta.mainProgram}
 
     runHook postInstall
   '';
 
   meta = {
-    description = "The Jule Programming Language Compiler";
+    description = "Jule Programming Language Compiler";
     longDescription = ''
       Jule is an effective programming language designed to build efficient, fast, reliable and safe software while maintaining simplicity.
       It is a statically typed, compiled language with a syntax influenced by Go, Rust, and C++.
@@ -95,7 +94,13 @@ stdenv.mkDerivation (finalAttrs: {
     homepage = "https://jule.dev";
     changelog = "https://github.com/julelang/manual/releases/tag/jule${finalAttrs.version}";
     license = lib.licenses.bsd3;
-    platforms = lib.platforms.unix;
+    platforms = [
+      "x86_64-linux"
+      "aarch64-linux"
+      "i686-linux"
+      "x86_64-darwin"
+      "aarch64-darwin"
+    ];
     mainProgram = "julec";
     maintainers = with lib.maintainers; [
       adamperkowski

[koibtw]

@FliegendeWurst thanks, applied :)

[philiptaron]

Since julec is a self-hosting compiler, doesn't this want to now re-compile the julec code using the newly built julec, then have that be the output of the derivation?

[koibtw]

Since julec is a self-hosting compiler, doesn't this want to now re-compile the julec code using the newly built julec, then have that be the output of the derivation?

Yes, that'd be the case for implementations like julec-git for example but since julec would generate the same IR (with --opt L2) and compile it with the same -p flag (see here), it's just a waste of compiletime here.

[philiptaron]

If it's going to be bit-for-bit equivalent, that'd make an excellent test for future updates.

Maybe put it in passthru.tests.recompile-equivalence.

I built this a lot of different ways (julec, pkgsLLVM.julec, pkgsStatic.julec, pkgsCross.aarch64-multiplatform.julec) and it all compiled, though the errors the C++ compiler emitted made me think that some of the codegen might not be tuned appropriately. Not a concern when introducing a new compiler package though.

Request completed.

[koibtw]

If it's going to be bit-for-bit equivalent, that'd make an excellent test for future updates.

Good idea. Unfortunately, it's not. If I had to guess it's due to the use of unsorted maps in IR generation. The Arch AUR packages use basic std tests transpiling for testing. This could be implemented here as well, although it doesn't really test much.

Also, clang is the preferred default backend compiler (see here). Is there a way to make it the default here or something like that?