Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
An interesing thought
#11
thank you DSMan195276 Smile
Reply
#12
I would add that I do think there's a fair amount of value in enabling the compilation of dlls or static libraries (`.a` or `.lib`). We're just not there yet, unfortunately Undecided
Reply
#13
Much easier would be to permit main code/declarations between and after subs/functions so we don't need *.bi and *.bm anymore but only one include that contains the declarations and subs/functions
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience
Reply
#14
(07-26-2024, 10:45 AM)mdijkens Wrote: Much easier would be to permit main code/declarations between and after subs/functions so we don't need *.bi and *.bm anymore but only one include that contains the declarations and subs/functions
I agree with your point, but the benefits of allowing easier QB64 code inclusion via `'$include` are a bit different from allowing compiling code into static libraries, dlls, `.o` files, etc.

For one, like @Doppler mentioned at the very beginning of the thread, if you compile to a `.dll` or `.a` then you could potentially expose a set of functions to be called from other languages. It's unclear what exactly that would look like, but it's possible we could support it in some fashion.

The even bigger thing would be the build advantages. If you could compile a `.bas` file to a `.o` or `.a` then you could compile all of your `.bas` files separately and link them together at the end. This would be faster as you could run the builds in parallel or only build the parts that changed, and it would also be more memory efficient compared to what we do now. It also has advantages over the .bi and .bm solution because you would have the ability to only expose a subset of the functions in the `.bas` file to the rest of the code, something that's currently impossible.
Reply




Users browsing this thread: 4 Guest(s)