Skip to content
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

[discussion] Build tools #107

Open
brantwedel opened this issue Feb 17, 2018 · 4 comments
Open

[discussion] Build tools #107

brantwedel opened this issue Feb 17, 2018 · 4 comments

Comments

@brantwedel
Copy link

brantwedel commented Feb 17, 2018

Working on a build tool similar to "webpack" or "make", written in kerboscript. Just wondering if I should make a PR to this library when it is ready, or if it should be a separate repo.

Also opening a discussion for what build tools / workflow would be useful. Ideally, tools that can be written in kerboscript.


You can take a look at it here in the meantime, lots of abstractions to work out, code to refactor: master...brantwedel:bw/lib-pack-initial

Notable features of lib_pack:
  • smart minification / local name minification.
  • inlining of "run" statement files (optionally as single line so the main file maintains line numbers for debugging)
  • recursive run file lookups.
  • c/c++ style compiler directives for toggling code/functions.
  • TODO: plugin system for additional functionality

Example lib_pack supporting json library (PR coming, with or without #directives, depending on results of this discussion): https://gist.github.com/brantwedel/218147d6fde9e6da8855646fcacef286

Note: Looking through the history, this discussion is similar to #6 but with a bit more reach than just a stripper (also an "auto doc" plugin would be nice, and maybe sourcemaps for debugging single line minification).

@meltingSnowdrift
Copy link

Inlining of files may change the meaning of programs because the separation between files affects variable scope. From the changelog in the documentation:

File scope was also modified so that each file properly defines a scope. This means that local variables declared in script files called from other scripts are no longer treated as part of the global scope. It also means that script parameters are local to the file itself and will not overwrite global variables.

@brantwedel
Copy link
Author

Good point! Altho, with the local name minification/obfuscation, you should be able to maintain the original file local scoping.

@meltingSnowdrift
Copy link

Would such a system also correctly treat variables declared as global in a file to make it accessible across all the files of the project? In a simpler but related case, how would it treat global variable declarations that occur inside functions but are still global to the file? (I am not sure if they are also global to the project.)

@brantwedel
Copy link
Author

brantwedel commented Dec 25, 2019

Yes, the minification shouldn't change/minify globals, only locals, since it can't know if globals might be used in other files etc., so should be no behavior change there regardless of if globals redefined in a function since globals are shared between scopes.

Altho, my initial example packing tool doesn't fully handle lazyglobals:
TODO: https://github.com/brantwedel/KSLib/blob/9037e446661de6cb70b028e4fb38d549f5773e0b/library/lib_pack.ks#L545
Docs: http://ksp-kos.github.io/KOS/language/user_functions.html#accidentally-using-globals

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants