Building projects or whole solutions?

[AudriusButkevicius]

There doesn't seem to be any explanation on how to build larger projects/solutions.

Is that even possible?

[MichalStrehovsky]

bflat build without specifying the input files will look for any *.cs files in the current directory. If you need more control, you would specify the file names explicitly.

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.

[AudriusButkevicius]

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?

[voronoipotato]

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.

[AudriusButkevicius]

Can you elaborate how the code should be structured?

Also how to deal with nuget dependency graph?

[voronoipotato]

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.

[MichalStrehovsky]

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.

bflat build foo.cs bar.cs produces an executable you can run (same way gcc foo.c produces an executable). This is for quick consumption with small things.

But you can also do:

bflat build-il foo.cs bar.cs -o:MyAssembly.dll
bflat build program.cs -r:MyAssembly.dll

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:

bflat build -c program.cs

This is the same as the -c argument to clang: it says compile to object file, but don't run the linker. You can then run the linker manually. (You can use bflat build -x program.cs to have bflat tell you how it invokes the linker so that you know the correct invocation as a starting point.)

[AudriusButkevicius]

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.

[MichalStrehovsky]

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:

bflat/src/bflat/bflat.csproj

Lines 200 to 216 in 200c770

	<ItemGroup>
	<BflatArg Include="@(Compile->'&quot;%(Identity)&quot;')" />
	<BflatArg Include="--os:%(SupportedHost.OS)" />
	<BflatArg Include="--arch:%(SupportedHost.Arch)" />
	<BflatArg Include="--no-globalization" />
	<BflatArg Include="--no-exception-messages" />
	<BflatArg Include="--no-pie" />
	<BflatArg Include="-o:&quot;$(LayoutsDirectory)%(SupportedHost.Identity)\$(BflatName)&quot;" />
	<BflatArg Include="@(RuntimeCopyLocalItems->'-r:&quot;%(Identity)&quot;')" />
	</ItemGroup>
	<WriteLinesToFile File="$(IntermediateLayoutOutputPath)\runbflat.rsp"
	Lines="@(BflatArg)"
	Overwrite="true"
	WriteOnlyWhenDifferent="true" />
	<Exec Command="&quot;$(RunCommand)&quot; build @&quot;$(IntermediateLayoutOutputPath)\runbflat.rsp&quot;" />

(Or you can just use the built-in PublishAot option and skip bflat completely. The main advantage of bflat is in the seamless crosscompilation and ability to use without MSBuild. If you don't need that, just go with the built-in thing).

Can library outputs have a dll entrypoint (DllMain)

DllMain is not directly exposed because running managed code under loader lock would be asking for trouble. You can use [ModuleInitializer] to sort of get similar semantics.

Also, not obvious how to export symbols from your dlls as C ABI

Did you see the sample?