Project Management v0.1

[Wodann]

To support multi-file Mun libraries, we need to come up with a project management system that allows users to easily setup, build, and tweak packages.

A Mun project will look as follows:

The main directory contains a src directory and mun.toml configuration file. All files in the src directory are automatically added to the build tree. This is different from Rust in that you cannot/do not have to write mod a in your source code.

A sub-module can be created by either:

• adding a directory a with a mod.mun file; or
• adding a a.mun file in the parent directory.

The above screenshot shows both of these examples for illustrative purposes.

To use a struct Foo, defined in src/a/b.mun, you can access it in the current file by writing: use a::b::Foo;.

By default, a type or function defined in a module is not accessible outside of its file and sub-modules. You can expand accessibility in three ways:

• pub: accessible within the package and externally (incl. marshalling to the host language)
• pub(package): accessible within the package
• pub(super): accessible within parent module and its sub-modules

A mun.toml contains information about the package, similar to a Cargo.toml:

[package]
name="test"
version="0.2.0"
authors = ["Mun Team"]

Depends on

• Add language support for specifying pub(...) scope #248
• Add language support for use statement #249

Improved by

• Export types from assemblies and store them in the runtime #145
• Replace TypeInfo with TypeRef in Runtime FFI #168

Remaining issues moved to later milestones

• Add more runtime tests to verify that runtime linking and hot reloading of files works #425

[nilq]

Looks reasonable. I like this structure; it provides a nice mix between especially Rust's modules, but also Lua's module system. Would the mun.toml file be required for all Mun-libs?

[baszalmstra]

The goal was to create something that is a bit simpler than Rusts method but without losing the ability to seperate functionalities. The design is also inspired by Typescript/Javascript.

I think the mun.toml file will be required yes. WDYT @Wodann ?

[Wodann]

I don't see how we could not have a config file. We could do without the currently listed items for sure, but going forward we'll want to add settings such as:

• Hot reloading granularity: per-file, per-module, per-package
• Dependencies

Those will require a mun.toml file for sure.

[Wodann]

To add to my previous comment, we want to have full compile flag support alongside the mun.toml file. For those people who don't want to use our project manager, they can use compiler flags instead.

[nilq]

That does make a lot of sense, for more independent libraries. Having an extensible mun.toml seems like a solid choice. It also a allows for a potential package manager in the future. I very much approve of the overall package management system 👍

[baszalmstra]

It also a allows for a potential package manager in the future.

That's definitely the goal.

[AlexCouch]

With beagle-lang I was planning on in the future adding a build system where I had build scripts in each of the modules that needed custom build scripts.
Example w.r.t Beagle-lang's planning project system

root
   | - src
        | - main.bg
        |- a
            | - mod.bg
            | - build.bg //A custom build script for module `a` such that what needs to be customized for `a` stays in `a`.
        |- b.bg
    | - build.bg //Main build script for the entire project, which acts as a globally applied script for all modules. This might include dependencies that all modules share, locally defined libraries, output directory, environment variables, etc

With this kind of structure, we can have modules that have more complex build scripts such as a module whose submodules are compiled for different platforms. Such as a module a that has 3 platform-specific implementations. The build script in a could specify common dependencies and settings, while the build scripts inside the platform-specific modules have slightly different dependencies for their platforms, and target information.

The structure would look something like this

fun build(builder: Builder){
    //A method which takes the name of the artifact which becomes the name of the binary and takes a lambda argument for decorating the artifact
    builder.createArtifact("artifact_name"){
        //A method which takes a lambda argument which returns dependency information. This can be used within a DSL for more complex stuff such as getting context about the current build session such as environment variables, machine information, etc
        builder.addDependency{
            //Logic for adding a dependency
        }
    }
}

However, the same effect could be done with *.toml files, and quite possible done much simpler with less hassle perhaps? And perhaps a DSL would be overwhelming to some people. Thought I'd share my thoughts here too.

[Wodann]

Interesting. It reminds me of the Unreal Build Tool.

A *.toml approach is a little less extensive, but in the general (most common) case simplifies things a lot.

[baszalmstra]

One of the main reasons I want to use a configuration file (*.toml, or whatever) is that its easily machine readable. This makes it much easier for tools to parse as well without requiring a very complex setup.

[baszalmstra]

I've been tinkering with the implementation a bit. I currently run into this question:

Currently, we have the mun build file.mun command. Should we change this to just mun build which you should run in the root of the package? (Similar to cargo build)

[Wodann]

Yes, we could do that by default. Two comments w.r.t. that plan:

1. cargo build still has a --manifest-path option to specify a path to the Cargo.toml file
2. If we remove the build command for compiling source files, maybe we should introduce the cargo compile command for people wanting to use a non-Mun package manager project. This would specify files and flags, akin to rustc.

[baszalmstra]

@Wodann Ah cool, I'll add the--manifest-path then.

I think we can add the compile command later. I don't see a direct use-case for this.

[baszalmstra]

All functionalities have landed in main. Closing this issue.