Skip to content

Improving asbuild #11

Open
Open

Description

@dcodeIO

From discussion in Discord lately it appears that there are some problems introduced by the asbuild package that may or may not have been avoidable, not sure. I am certain that there are good reasons to provide asbuild separately, but given that I raised concerns initially in an attempt to avoid as many problems as we can, even though matters didn't go as I had wished, I'd like to reconsider what we can do from here to improve the situation.

  • What are the concrete problems with asbuild currently?
  • What does asbuild provide concretely that the main package doesn't?
  • And an inconvenient one: Would an asbuild script next to asinit, as initially planned (more powerful npm run asbuild), be sufficient already?

Activity

  1. dcodeIO commented on Feb 21, 2021

    @dcodeIO
    MemberAuthor
  2. willemneal commented on Feb 23, 2021

    @willemneal

    Thanks for looking into this. For the first, it seems that @MaxGraey found the root of the issue mentioned above and I have an open PR to fix it.

    As I've mentioned previously the goal of asbuild is to be a tool on top of the compiler. Currently this means:

    • defaults for entry file (assembly/index.ts) if none is provided
    • defaults for where to place the binaries, what its name should be, and allowing --wat to produce a wat file.
    • allows for workspaces
    • defaults for targets, debug and release are what you would expect if you don't provide them

    Goals for what it could be:

    • handle binary caching.
    • package as-pect to allow for asb test.
    • Make it more modular like cargo, so that other tools can integrate with it.
    • Could replace npm for AS projects with dependencies on other Wasm projects
    • Handle merging Wasm binaries (given an interface types section)

    Other thoughts

    As we move asc to AS, it could be a good time to separate out the configuration logic for parsing asconfig.json files, which then asbuild could borrow, (currently this is a limitation of asbuild since it doesn't merge configuration files like asc does).

    As you can tell my dream for this project has perhaps a broader scope than just asbuild as that is but one portion of the larger project management features listed above.

    Perhaps we could rename this project to hanger (for a rocket ship hanger)

  3. ColinEberhardt commented on Feb 23, 2021

    @ColinEberhardt

    As I've mentioned previously the goal of asbuild is to be a tool on top of the compiler. Currently this means:

    • defaults for entry file (assembly/index.ts) if none is provided
    • defaults for where to place the binaries, what its name should be, and allowing --wat to produce a wat file.
    • defaults for targets, debug and release are what you would expect if you don't provide them

    Personally I'd suggest that these are features / fixes that should be applied to asc directly, rather than indirectly via a tool that wraps asc.

    The other goals mentioned sound like more useful extensions :-)

  4. willemneal commented on Feb 23, 2021

    @willemneal

    @ColinEberhardt, well I personally agree too my main argument against those features in asc is that we should aim to keep as simple; the same reason those are not provided in projects like rustc. Plus it makes it less opinionated if you wanted to build a different build tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions