Skip to content

Unify and fixate srcdir and builddir #54

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tim-janik opened this issue Feb 25, 2024 · 1 comment
Closed

Unify and fixate srcdir and builddir #54

tim-janik opened this issue Feb 25, 2024 · 1 comment
Assignees
Labels
bug Something isn't working
Milestone

Comments

@tim-janik
Copy link
Owner

Currently we have source root, build root and npm root mismatches that cause significant problems.

Many C++ projects support srcdir!=builddir (automake) or even advocate for it (cmake). Javascript (nodejs) projects generally expect srcdir==builddir, these place package.json at the root dir, which is often accompanied by a package-lock.json to recreate identical package installations. In addition, defaults for the build process are stored in a writable srcdir/config-defaults.mk file and in order to allow reliable scripting, our release creation scripts will create packages in srcdir/assets/.

Currently, the package.json script used by Anklang is stashed away in misc/package.json and copied into out/ (the default builddir) at build time. npm/bun/pnpm will then create package-lock.json and node_modules/ next to it under out/package.json, out/package-lock.json and out/node_modules/. This leads to many Javascript tools working properly only under out/. E.g. linters like eslint or tsc cannot properly deal with source files outside of the out/ hierarchy, e.g. they fail to process includes properly or flat out refuse to process files outside of the out/ hierarchy. This leads to lots of important source files having to be copied into the out/ hierarchy (usually under out/ui/) which mostly enables the Javascript ecosystem tools to work properly but creates its own set of annoyances:
a) Attribution of source file errors/warnings is incorrect (so IDEs cannot directly jump to source locations), b) development tools and build scripts have to be copied into deployment locations like out/ui/, c) hot-reload watch functionality needs extra scripting to include an out of tree location, d) inplace edits of errors/warnings are easily accidentally overwritten, e) make clean may delete newly created source files that had to be created and edited under the build hierarchy in order to utilize tooling, f) file edits in the build hierarchy cannot benefit from hot reloading, g) Github bots that can check and report on outdated software packages or vulnerabilities cannot find the package.json in the project root, etc...

I.e. the more we utilize tools, libs, integrations and assets from the Javascript ecosystem, the more painful it gets to have the above mentioned separation. Given that modern Git supports multiple checkouts in arbitrary workdirs, and that upholding srcdir!=builddir separation creates increasing hurdles for working with the JS ecosystem, we should simply fix the builddir location per srcdir hierarchy, and most importantly move package.json (and therefore node_modules() to the project root, i.e. srcdir/. This will also simplify a lot of the Makefile.mk logic currently under ui/.

The transition can start with just moving package.json to the project root and adapting a handful paths. Simplification of Makefile.mk rules that currently have to jump through extra hoops, can happen incrementally after that.

@tim-janik tim-janik added the bug Something isn't working label Feb 25, 2024
@tim-janik tim-janik self-assigned this Feb 25, 2024
@tim-janik tim-janik added this to the v0.3.0 milestone Mar 4, 2024
@tim-janik tim-janik modified the milestones: v0.3.0, v0.4.0 May 24, 2024
@tim-janik
Copy link
Owner Author

Closing this, we now have package.json and node_modules/ in the root, which fixes most problems.

@tim-janik tim-janik modified the milestones: v0.4.0, v0.3.0 Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant