chalet-org / chalet Goto Github PK

At the moment, .sh scripts always launch a subprocess with bash, but it should respect what's defined in the shebang.

Even if the script is executable, the subprocess still requires the first string in the command to be the shell executable. So read the first line of the file, check for the shebang & use that, or default to bash (or the system's default shell if possible).

Would need the Xcode project / Swift stuff first most likely

Kind of half-assed this when I was looking at the DependencyManager again.
Get all the git-related stuff into this new class, and make it work nicely with the DependencyManager.

• Phase out shortDescription & longDescription
• inline macos bundle Plist
• mainProject
• Run a script
• Windows: manifest is a noop
• Mac: When lib is dist, make sure rpath to self gets changed to cwd instead of build folder (like w/ executables)
• boolean property to toggle dependency gathering

CMake has a couple ways of doing this, but something that would be friendly to the Release build could be scripted with:

git clone [--quiet] -b [tag|branch] [--single-branch|--depth 1] --config advice.detatchedHead=false (repo) (destination)

Definitely test with the CI build too (barf)

Makefile/Ninja issue...

Situation:
Initialize an Objective-C project w/ precompiled header

because .mm files can't be used w/ precompiled headers, the pch doesn't build yet. It's not much of an issue yet, but then if you add a cpp file after the first build, the cpp file doesn't build because it wasn't known at the time the makefile was generated

Can't step through Debug build in VS Code at the moment - hopefully just missing some cl options

Basically: You should be able to bundle a shared/static library, not just an executable.

Do this in the shared lib example project

Keep forgetting to actually do this...

• Sign at bundle time
• macosSigningIdentity setting in cache - copied from global config.
• If macosSigningIdentity not set, no error - don't sign
• Actual cmd should happen in AncillaryTools - owns macosSigningIdentity
• Make sure this works in github actions

https://localazy.com/blog/how-to-automatically-sign-macos-apps-using-github-actions

${externalDepDir} - maybe just remove?
${external}
${vendor}

Described here:
https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary

-build each arch
-"lipo" tool to combine them

In practice:

• Some kind of "universalBinary" option in the bundle
• When bundle is called, the selected arch is built as usual, then at bundle time, the opposite arch is built, with a modified CommandLineInputs object and separate state
• Join each binary together into a "universal-apple-darwin_(config)" build subfolder
• Then use those for the Bundle - need to make some heavy changes related to state, but would be better in the long run.
• During bundle, dependencies also need to be universal - for instance, some file coming from a CMake project
• rpath stuff
• Cleanup

You can do this manually with a resource, but it looks like CMake implicitly creates one and links it

...  /MANIFEST /MANIFESTFILE:CMakeFiles\chalet-debug.dir/intermediate.manifest CMakeFiles\chalet-debug.dir/manifest.res"

This should be easy to do. The basis for this is in MsvcEnvironment.

• Default to Ninja if using MSVC
• Finish toolchain commands
• Test alongside NMake

https://cmake.org/cmake/help/latest/manual/cmake.1.html

• -C - build script
• -A - would tie into "arch" somehow
• -T - toolset
• -B - set build directory to build/(config)/(external)/(name)

This involves direct calls to cl.exe and link.exe via NMAKE. At the moment, if you're building using the makefile strategy with MSVC, it implies NMAKE and uses its own generator since the syntax is a bit different.

• Inherit MSVC Environment (done-ish)
• Translate GNU syntax options to MSVC options (partial)
• Finish command parsing
• Improve source/dependency file lookups. What's there now is kind of hacky
• Check if parallelization is okay

This is directly related to the folder hash.

The fix I think is to change builddir to something like "build/.cache/Release" and make the build.ninja file the hash

It's getting unruly in places... Controller/view might make more sense now.

Home folder (probably?) - .chaletconfig

Settings:

• certSigningRequest file - needed for signing on mac
• Mirror "settings" in chalet-cache & import them into cache on first build
• command line interface - mimic git (chalet config --global maxJobs 8)

At the moment, there's a separate schema for scripts as opposed to a normal build step. The same could be done for CMake instead of rolling it into the project schema.

It's a little strange to have msvc.env when mingw is used, however it gets generated before the compilers are detected, so maybe remove it afterwards and don't even do the check? not sure how this would work yet...

• MSVC
• MinGW / MSYS
• Clang
• Use arch in build folder paths (x64_x64_Debug)
• Should be able to build the same config for 2 arches w/o recompile (x64_x86_Debug & x64_x64_Debug)

It's hard to say what arch would ultimately do in the build.json.
For MSVC at the very least would use the x86 & x64 compilers.

For AppleClang, I think it would just be x64 & ARM

GCC has a ton of architecture related flags, and I don't think arch should control those because they get too specific. If you're targeting embedded, you should just use the generic compileOptions & linkerOptions

Maybe find out how CMake handles that stuff...

https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html#Submodel-Options

There's a bunch of these in the Target classes (ProjectTarget mainly).

• Move the entire string vectors into the functions, since their strings get moved out anyway.

Another can of worms. At the very least, it should build from a Gradle config.

At the moment, it's 1 build.json = 1 bundle, but that can def be improved.

Also, move BuildStrategy over to MetaStrategy concept... and ultimately back to just BuildStrategy, that creates the cached file & builds in seprate steps.

The wip exploration is in xcode-project.json and the "Build: Release (Xcode)" task, and hook into XcodeGen via Swift.

https://github.com/yonaskolb/XcodeGen

My original thinking:

1. Generate an xcode-project.json (into the build folder) from build.json
2. Call XcodeGen via Swift and pass it the xcode-project.json path and other options
3. Save the xcode project path to the build folder or something

The problem with this is, to go through Swift, part of Chalet would need to be built for Swift and Objective-C++

Objective-C++ support in Chalet works, but interfacing with the Swift compiler is not a thing yet

The alternative is to figure out Xcode project generation from a purely C++ way

2022:

• export route
• "xcodebuild" build strategy
• check for xcodegen & tell the user to install it from brew if they don't have it
• generate the spec file in json
• adapter architecture that plays nicely with the existing apple clang generators
• support all the things
  • Figure out variables needed for each build configure instead of using default debug/release presets
• pass the spec file to xcodegen and generate the project in the export folder
• call xcodebuild at the command line like with msbuild... it should be pretty similar code

https://xcodebuildsettings.com

2023:

• remove xcodegen dependency. start here: http://www.monobjc.net/xcode-project-file-format.html
• appleProductBundleIdentifier - warn if not set, and default to com.myapp.target-name or something
  • don't worry about this

On Non-Windows, MSBuild is used for Mono/C#

On Windows, it could be used for C# and C++ projects. One could define an existing C++ project, or generate one.

Native-only, remove from strategies.

Serves as a template for #16

Example scenario: chalet-example-* projects are used as externalDependencies, so they're pulled down from git, and then built using their own configs. This should be a separate build step schema, much like scripts

macOS's is pretty robust, so it would be nice to get MSVC's to that point, but not sure yet what VS tools allows from the command line...

GCC to start with - testing w/ TDM GCC 4.8.1 (mingw)

This toolchain is especially weird, because although it's based on LLVM / Clang, and it has its own underlying executables, the primary executables, emcc & em++ are... python scripts.

• Load emscripten environment
• Perform initial checks and get to building phase
• build a basic Hello world
• 'run' calls emrun and serves the program through localhost
• build shared & static libraries - .wasm for shared libraries, following their docs
• Get CMake targets to compile
  • Inconsistencies in the output file - doesn't generate an html
• Run through all chalet options to see what does and doesn't work
• Disable profiling
• Test all build strategies
  • Native strategy needs to invoke emc differently on windows
• Option to provide a custom shell
• dumpAssembly - should generate .wat files (WebAssembly text format)
• Figure out source target + cmake library target interop
• Get Debug build working inside browser debugger
• Disable exporting (in everything, maybe?) - VS Code might be work in some way
• (deferred) Test out GLFW example - v0.7.x branch, not quite working yet
• Test out SDL example - works great on v0.7.x branch
• Test out SFML example - fails - Unsupported operating system or environment
• Distribution stuff

VS Code extension:

• Update signal handling to match changes that were added for canceling the server correctly

Docs:

• Most important thing is that the emscripten toolchain requires EMSDK set to where emscripten was cloned
• Assembly dumping requires wasm2wat from either brew - wabt or https://github.com/WebAssembly/wabt
• web platform property condition was added
• Debug builds serve the working directory in order to resolve source maps to their cpp files. Debugging in general is kind of odd, because stepping through a cpp file is actually stepping through a wasm file, so there could be multiple instructions per line. It's not obvious right away. Not sure yet of what repercussions this would have on serving images for texture loading in say a game
• User can set EMRUN_PORT to change the port the server runs on
• For the custom shell, recommend the following in the executable's settings:

"linkerOptions[toolchain:emscripten]": [
   "--shell-file",
   "path/custom-shell.html"
]

The main issue is, a folder gets created if a bogus arch is passed in.

Clang prob has something for this. gcc is kind of locked into whatever it was built for (so -dumpmachine would be fine). ignore/fallback in msvc for now I guess.

No dependency management yet at all. At the moment, the native-experimental strategy is used as the default in CI builds since deps are not needed there, but locally, it's not really a viable option.

The way to do this I think would be to read through all the *.d files and consolidates them to a single list, goes through the list, gets the timestamp for each file, then compares them with the previous timestamp.

MSVC: *.d files have to be parsed from /showIncludes

Not sure who would even use this, but it's a thing... someone might want to run a .ps1 script on macOS or Linux.

https://github.com/PowerShell/PowerShell

Don't throw an exception if the build.json parser found an issue - just use Diagnostic::error and return false. This also means keeping error checks outside of state classes.

Iterate through all projects and generate a single .ninja file for them.

+Fixes dependency restat issues if two build projects share the same files

• The main downside to this is that it breaks the concept of running a script before/after a certain build step

Look into it more closely - If there are 2 bundles where one is Release and one is Debug, it doesn't seem to work right

• Bundle needs to reference its own version of buildConfig - paths.buildConfig gets set once
• Build needs to run for each configuration referenced. If there's a bundle with Debug, and one with Release, both Debug & Release need to build

Use cmake --build instead of calling make/ninja directly after the project has been generated. Defer all responsibility to CMake ;)

At the moment, there's just a flag for posixThreads, but it would make more sense to say "threads": "posix" instead.

MinGW has a "-mthread" option, which is presumably synonymous with windows threads... more research.

MSVC would use Win32 threads unless it was targeting Linux (don't even want to think about that yet)

Options:
posix - prefer pthread, would use pthread option in MinGW, MSVC would presumably use pthread if targeting Linux
auto - pthread on non-Windows, Win32 threads on Windows

Also, move windows.icon out of bundle - it's a noop

It's just a pile of spaghetti right now...

Add some kind of framework for Package Managers vs Version Control repositories