Open dronelektron opened 5 months ago
This feature was dropped a while ago. I can look into re-adding it.
Sadly. I think it would be good to re-add it if it does not complicate the code base too much.
I like C style
projects, when you have only headers
in source files, but source files
are attached to the compiler for linking.
This will hide the long and scary paths to the source files of other plugins, and make the build process more flexible.
My main motivation here is that it's better than having a "main.sp" that includes a bunch of source files. Also, many modern languages treat same-dir files as automatically part of a single package/module. It seems like a natural direction to go.
The reason it got removed was during the transition to the new parser. That transition is long done, so we should be able to re-add this.
This is going to be harder than I thought. The old compiler would concatenate all the source files together, which meant they had to be correctly ordered on the command line. I don't want to do that. Each source file should compile independently and then get linked together, which also means they should each get their own global scope, and have to re-import includes. Unfortunately... we don't have a linker, and I don't want to write one, since that's neither a useful nor a productive use of time.
So I'll think about this a bit more.
Most likely the real answer is to finally write a replacement for #include
, which multi-source projects would be obliged to switch to.
Thank you for taking the time to look into this issue. It's sad that the language has everything except a linker. It would be very cool to turn into a normal scripting language without boilerplate code, where each file can be treated as a module with its own constants, functions and more.
Spitballing a bit, I can see this going in 3 directions.
(1) Runtime linking. Compile every file into its own .smx - including stuff like sourcemod.inc
. The compiler would put these all into a single container. The VM would open the container, and link everything together in memory. This is how Java/C# work (.jar files are just a zip of .class binaries). It would enable a run-as-source model. It'd be moderate changes to spcomp and heavy changes to the VM.
(2) Compile-time linking, with AST merging. We'd build separate in-memory ASTs and symbol tables of every file, aggregate them together, then generate one big .smx file, as if they were never separate to begin with. It'd be heavy changes to spcomp and no changes to the VM.
(3) Compile-time linking, with SMX merging. We'd do all the stages of compilation, then do the runtime linking from (1) that would have been in the VM, then write it out. Probably the most work of any option, but wouldn't require as invasive refactoring of the compiler as (2).
I'll think about it for a little while.
Help us help you
Environment
Description
A project consisting of multiple source files either does not compile or produces a warning.
Problematic Code (or Steps to Reproduce)
File:
plugin.sp
File:
module.sp
Logs
If you change the order of the source files to
module.sp plugin.sp
, you will get the following:If you add the
public
keyword before theModule_Foo
function, the project will compile, but the function will not be called: