Add Makefile for common Rust development tasks

[Copilot]

Makefile for Rust Accumulator

• Create comprehensive Makefile with standard Rust development targets
• Modify Cargo.toml to build only static library
• Create pkg-config template file
• Implement pkgconfig and install targets with INSTALL env var requirement
• Add clear error messages for missing requirements
• Squash all commits into a single commit
• Update co-author attribution to "Erik de Castro Lopo erikd@mega-nerd.com"

Original prompt

Please create a Makefile for this project

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[erikd]

@copilot Please add creation of a pkg-config file

[Copilot]

@copilot Please add creation of a pkg-config file

Added make pkgconfig target to generate pkg-config file and make install target to install the library and pkg-config file. The pkg-config file is created at rust_accumulator/target/pkgconfig/librust_accumulator.pc and version is dynamically extracted from Cargo.toml. The install target supports Linux (.so), macOS (.dylib), and Windows (.dll). Commit 1a5821f.

[erikd]

@copilot Please only build a static lib and make it installable in the directory tree specified by the $INSTALL environment variable. If that enviroment variable is not specfied it should fail with a nice error message.
The pkgconfig file should be generated from a template file with a "pc.in" file extension.

[Copilot]

@copilot Please only build a static lib and make it installable in the directory tree specified by the $INSTALL environment variable. If that enviroment variable is not specfied it should fail with ...

Changed to build only static library (.a file) by modifying Cargo.toml crate-type to ["staticlib"]. The pkgconfig and install targets now require the INSTALL environment variable and fail with a clear error message if not set. Created librust_accumulator.pc.in template file for pkg-config generation with @Prefix@ and @Version@ placeholders. Commit 01dcf63.

[erikd]

@copilot Please squash this PR down to a single commit, and refer to me as "Erik de Castro Lopo erikd@mega-nerd.com"

[Copilot]

@copilot Please squash this PR down to a single commit, and refer to me as "Erik de Castro Lopo erikd@mega-nerd.com"

Squashed all 6 commits into a single commit (3a74099) with proper co-author attribution to "Erik de Castro Lopo erikd@mega-nerd.com".

The commit is ready locally but requires a force push to update the remote branch since the history has been rewritten. Due to authentication limitations in my environment, I cannot complete the force push.

You can complete this by running:

git push --force-with-lease origin copilot/create-makefile-for-project

Or I can provide an alternative approach if you'd prefer.

[erikd]

I have tested this and it seems sensible to me, although I have had very little exposure to Rust.

[locallycompact]

I really don't want to support a Makefile. They are untyped and they will not get caught by CI. Is cargo not enough here?

[perturbing]

This breaks the nix build somehow

       > Configuring library for haskell-accumulator-1.1.0.0...
       > Warning: [unknown-directory] 'hs-source-dirs: test' specifies a directory
       > which does not exist.
       > Error: [Cabal-4345]
       > Missing dependency on a foreign library:
       > * Missing (or bad) C library: rust_accumulator
       >
       For full logs, run:

[perturbing]

I really don't want to support a Makefile. They are untyped and they will not get caught by CI. Is cargo not enough here?

I think it is okay to have it, as when we fully integrate this in Hydra, people will not only build via Nix.

[locallycompact]

Anything that isn't captured by CI will inevitably break and become a future problem. We can not have files that aren't covered by CI and making the nix depend on the Makefile is not a great developer experience.

What we have done in the past is a Shakefile, and then have the nix outputs directly refer to the shake outputs and provide shake through the devshell. This worked quite well for us for building Agda for example. It at least means we can have let bindings and functions in the Shakefile written in regular haskell, and the nix will just automatically error when the Shakefile changes.

[erikd]

I really don't want to support a Makefile. They are untyped and they will not get caught by CI. Is cargo not enough here?

Anyone that wants to use Cargo directly, can so so.

The Makefile is for people like me who do not really have much Rust experience.

[erikd]

Anything that isn't captured by CI will inevitably break and become a future problem. We can not have files that aren't covered by CI and making the nix depend on the Makefile is not a great developer experience.

What we have done in the past is a Shakefile, and then have the nix outputs directly refer to the shake outputs and provide shake through the devshell. This worked quite well for us for building Agda for example. It at least means we can have let bindings and functions in the Shakefile written in regular haskell, and the nix will just automatically error when the Shakefile changes.

Would this PR be accepted if a CI job was added to keep it working?