-
-
Notifications
You must be signed in to change notification settings - Fork 101
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
Building projects or whole solutions? #57
Comments
Bflat is just a compiler, not a build system. If the build is more complex, one would drive this from a build system. Makefiles, or even MSBuild targets. |
Sure, but if you have anything more than a few files this somewhat becomes unfeasible. Its also not clear how linking etc would work. One example that I have in mind is for example game modding. Currently I have to a solution with a project that declares base types for modding, and then a project per mod that uses the types from the base project. I then compile the mod project, have a small C++ dll that injects the CLR into the game and loads the mods via dynamic assembly loading. Ideally I'd like to avoid having to load the CLR and compile the mods (including project and nuget deps) to native code and inject them directly. Is that possible with this compiler or is this only usable for 2-3 file projects? |
You'd have to change the way you write and structure code but there's genuinely no reason you couldn't do this with 150+ file projects. This is less of a problem for F# since we (culturally) don't rely on that kind of polymorphism as much but there's no actual strict need to write your C# that way. |
Can you elaborate how the code should be structured? Also how to deal with nuget dependency graph? |
For your own code you should be able to essentially treat folders as projects using namespaces etc as you do in C# normally. For nuget you'll have to be more careful with what packages/versions you choose. If it becomes intractable there are tools like paket which are allow for more fine grained control and flexibility with package resolution. If my current understanding is correct, you probably won't be able to write your project with the kind of runtime modular approach that you're used to, so you should design with that in mind. |
The way bflat is structured is really no different from how clang, gcc, or other native compilers are structured. They scale to the extent of Linux kernel, Chromium browser, etc. with thousands of files.
But you can also do:
The first invocation produces an equivalent of a library csproj. The second invocation uses the library to create an executable (equivalent of Exe csproj). Depending on what you want to achieve, you can also do:
This is the same as the |
Thanks. Can library outputs have a dll entrypoint (DllMain)? Not obvious how to declare that from c# or how that gets exposed? Also, not obvious how to export symbols from your dlls as C ABI (I assume thats the usecase for supporting compiling to libraries) I guess it's a lot of manual work to do that for the whole solution but I'll give it a go see how far I get. |
If you have existing project files, you can just drive bflat from MSBuild. Bflat builds with bflat, but the bflat command line is constructed by MSBuild: Lines 200 to 216 in 200c770
(Or you can just use the built-in
DllMain is not directly exposed because running managed code under loader lock would be asking for trouble. You can use
Did you see the sample? |
There doesn't seem to be any explanation on how to build larger projects/solutions.
Is that even possible?
The text was updated successfully, but these errors were encountered: