Consider splitting out into groups

[woollybah]

It may be nice to split out the monster that is bah.mod into related groups of modules.

For example, audio, database, etc.

This would, of course introduce disruption by having module "go missing" from the core bah.mod.
But for the future, it may be worth the initial hassles, just to make using the modules a little less problematic - i.e. only use the ones you need.

Comments and suggestions are welcome :-)

[GWRon]

Yes. Splitting stuff would be good. Some stuff I also consider mandatory and should be provided in the NG releases already - eg. "Volumes.mod" as all of us should need to pay attention to user directories. Some stuff might be groupable but what about frameworks or "functionality beasts" doing more than gfx OR audio OR ...

[xlsior75]

Seems like a good idea -- right now, it's hard to keep things in a working/compilable grouping since many mods have dependencies on others, while at the same time many of them don't work properly with the current compiler stuff.

For example: With your latest downloadable bcc/bmk package that you posted yesterday, GCC 8.1.0, 28 out of the 144 bah.mod modules fail compiling using x64 on windows, or almost 20%. (With x86 a few additional ones won't compile that do work with x64).
(That includes some major mods like bah.magick)

(And IIRC with GCC 7.1.0 only about half of them compiled without error in both x64 and x86)

Since there are so many, you can't easily sync the entire bah.mod subtree into a 'live' install, since the build process is pretty much guaranteed to fail.

Splitting it up in smaller, related batches seems like a good way forward.

[braxtonrivers]

Awesome idea, personally I am all for it, I always thought the idea of a longer mod namespace for example mycustommod.gfx.gl.core, mycustommod.gfx.d3d9.core mycustommod.hardware.win.core or mymod.sfx.win.core etc would be cool as wedoe used this originally in vanilla BlitzMax with some of his modules where it was seemingly allowed but this namespace trick no longer works in NG sadly

…

On Wed, 12 Sep 2018 at 11:01 am, xlsior75 ***@***.***> wrote: Seems like a good idea -- right now, it's hard to keep things in a working/compilable grouping since many mods have dependencies on others, while at the same time many of them don't work properly with the current compiler stuff. For example: With your latest downloadable bcc/bmk package that you posted yesterday, GCC 8.1.0, 28 out of the 144 bah.mod modules fail compiling using x64 on windows, or almost 20%. (With x86 a few additional ones won't compile that do work with x64). (That includes some major mods like bah.magick) (And IIRC with GCC 7.1.0 only about half of them compiled without error in both x64 and x86) Since there are so many, you can't easily sync the entire bah.mod subtree into a 'live' install, since the build process is pretty much guaranteed to fail. Splitting it up in smaller, related batches seems like a good way forward. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXtwHjV3r8pVS9qL9pgXRoP_5RRho0wdks5uaFzrgaJpZM4Wi73c> .