More #include functionality

ID:1713711
 
Nov 5 2014, 2:30 am
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
It's quite annoying to have to manage a strict index of files, no matter how you slice it.
Huge monolithic ones like the .dme cause difficulties in collaborative projects and don't allow for any modularity, and sticking smaller ones in every folder clutters the source.
And of course, having to edit the index every time a file is moved/renamed isn't fun.
And then there's all sorts of tactics that may be needed to manage a large and complex project in a clear and maintainable way.

So it'd be nice to have some more options for #include, especially path operators, wildcards, and composition of defines and paths.

Current example:

// File structure
////////////////////////////////
//
// project
//     examples
//         style_red
//             example1.dm
//             example2.dm
//             example3.dm
//         style_blue
//             example1.dm
//             example2.dm
//             example3.dm
//         style_green
//             example1.dm
//             example2.dm
//             example3.dm
//         example4.dm
//         example5.dm
//         example6.dm
//     example7.dm
//     example8.dm
//     example9.dm
//     project.dme
//



// project.dme
////////////////////////////////

#define STYLE_RED
//#define STYLE_BLUE
//#define STYLE_GREEN

#if   defined(STYLE_RED)
#include "examples/style_red/example1.dm"
#include "examples/style_red/example2.dm"
#include "examples/style_red/example3.dm"
#elif defined(STYLE_BLUE)
#include "examples/style_blue/example1.dm"
#include "examples/style_blue/example2.dm"
#include "examples/style_blue/example3.dm"
#else
#include "examples/style_green/example1.dm"
#include "examples/style_green/example2.dm"
#include "examples/style_green/example3.dm"
#endif

#include "examples/example4.dm"
#include "examples/example5.dm"
#include "examples/example6.dm"

#include "example7.dm"
#include "example8.dm"
#include "example9.dm"

Proposed example:

// This is shown with strings and conc'n a la C99
// Since afaik that's closest to the compiler's internals
// So it'd be the most feasible way to do this
//
//   /   is the downwards path operator
//   .   is the upwards path operator
//   *   is a wildcard
//   ""  indicates a literal
//   ##  is concatenation
//


// File structure
////////////////////////////////
//
// project
//     examples
//         make.dm
//         style_red
//             example1.dm
//             example2.dm
//             example3.dm
//         style_blue
//             example1.dm
//             example2.dm
//             example3.dm
//         style_green
//             example1.dm
//             example2.dm
//             example3.dm
//         example4.dm
//         example5.dm
//         example6.dm
//     style.dm
//     example7.dm
//     example8.dm
//     example9.dm
//     project.dme
//


// style.dm
////////////////////////////////
#define STYLE "red"


// project.dme
////////////////////////////////

#include "examples"/"make.dm"
#include "example"##*##".dm"


// examples/make.dm
////////////////////////////////
#include ./"style.dm"
#include "style_"##STYLE/ *##".dm" //Space to avoid comment open?
#include *##".dm"

How feasible would it be to expand the pre-processor's #include command like this?
Even if the above example is completely impossible at the moment, what about smaller expansions, such as #include'ing a directory (ie telling the compiler to process everything in a certain folder)?

Nov 5 2014, 2:51 am
A related request was made a year ago:
http://www.byond.com/forum/?post=1411008
That also requests wildcards in #includes, though I'd personally prefer plain make.dm files instead of .dme's designed to be auto-generated.
Nov 8 2014, 9:01 pm
After careful testing (read: feeding random strings to the compiler-beast until it growls approvingly), it turns out the preprocessor actually HAS an upwards path operator, "..".

Example usage (including the parent project's copy of a library):
// Directory /////////////////////////////////////
/* 

 Folder for the "multiplayer notepad" project:

   /mpnotepad
       libraries
           bfparser
               make.dm
           markovmadness
               make.dm
           stringmongler
               make.dm
           regsex_engine
               make.dm

 Multiple libraries will depend on stringmongler.
 And we don't want to keep a copy for each.
 Instead...

*/
// Child Makefile ////////////////////////////////

// ...We're all going to #include the same copy!
// Each child's makefile (.dme or otherwise) can
// use this to do it:

#include "../stringmongler/make.dm"

// Or this:

#include "../../libraries/stringmongler/make.dm"
Apr 2 2015, 10:25 am
I would still like and use this.
Apr 2 2015, 10:26 am
Although, if http://www.byond.com/forum/?post=1767137 was implemented with a pre-build hook, then we could do this part ourselves.
Aug 26 2019, 4:05 pm
Dunno if necrobumping is frowned upon but boy would this be nice, especially since renaming a .dme seems to strip it of its entire list of #include statements. Won't let me simply add them back -- compiling and clean compiling strips them away. If we could define them ourselves, like here, and therefore have it not shoo away our changes, that would be dope.