Sorry your browser is not supported!

Avalible PreCompilers found on the forums:
DBP++ (C style Defines...)
ooDBP (Class Support...)

Design Preview uploaded 2007-March-06
RAR File is attached. DBPmC Should not crash. but be aware, its W.I.P ! compiling is disabled. same for pluginhandling (its just faking the plugin list same for compileing process)



DBPmC
This is a PreCompiler that will be able to call other precompiler EXE-files and supports easy to create plugins. Plugins use the JEDI Package (TJvPlugin) and will be created in DELPHI.

Features:
3 types of PreCompiler will be supported.
EXE-Standalone: just any exefile that does precompiling by itself
EXE-Piping: standalone provided with sourcefile, that outputs the the modified source to screen
Plugin: TJvPlugin that will be provided with a pointer to the source and modifies it.
Any plugin or PreCompiler that has a equally named file with the ending ".inc" will will be scanned for a <[[HILIGHT] ... ]> part and used. see below.

Special Includes
parts of the include files can be inclosed in tags that will place the the tag-content to its right place in the source file before compilation. tags can be commented out, so include testing in the editors will still work
<[[HILIGHT] ... ]>
adds the specified commands to the DBPmC Hilighter file for automatic use in editors. will not be added to source - (*1)
<[[INIT] ... ]>
TYPE and ENUM declarations that will be called on top of the source
<[[DEBUG] .... ]>
the marked area is used for testing the include in an editor and is displayed as example in the includes preview, will not be included in the source file for compilation
<[[REQUIRED] ... PLG:bla.dll ... EXE:bla.exe ... ]>
automated selection of required plugins, precompilers, includes. will not be added to source - (*1)

(*1) use remstart..remend instad of line comments to comment out the section for use in editor to be able to test the file

Setup
every editor can use this, since calling DBPmC without a parameter calls the setup. compiling just works the usual way. DBPmC takes the place of the original compiler, and calls the now renamed original compiler.

Project Dependend Configuration
DBPmC options can be saved globally (standart behavior) or be saved specially for a specific project.


ADDITION:
If an exe PreCompiler has "mode=piped" in its comments somewhere, the piped mode will be preselected in the "Load PreCompiler" -Settings.
DBPmC will support DLL creation, using your favorite IDE. you can use the standart commands - except any grafic related ones specific to DarkBASIC (its a DLL anyways, so no need for that). since DarkBASIC is not able to compile sourcecode to dlls, a DBPmC plugin will take care of this to create native WinAPI dlls that can be used in your projects (has to be downloaded seperatly-not in the standart DBPmC package).full pointer support. including a whole bunch of extra functions you can use in your DLL projects (mySQL, Lua, XML, zLib, Bass, CryptLib, Newton, WinSock, and other WinAPI related) - mind that those functions will only be able in the DLL but may be accessable if you write functions to export them. be aware that coding support is specifically supported for DLL creation!



Well the Point is:
There are a few ppl working on PreCompilers. The problem is to use all of them. You can only have one installed at a time. So this is intended to be able to call them one by one.

Since i was also up to create one, i thought i could extend this to a plugin system. I got a few ideas and including more and more, this could be a stable base. It allows to use PCs that are not intended for beeing able to be called seperatly.

Also to be able to auto-apply includefiles and for allready included files, add the possibility to move type defs to the top of the source, so compiling include files with type defs work without having to create gosubs and a like.

so...this just lets you create pre compilers? Like,what would this be used to make? Can you post an example of something cool and useful it could create? I mean,it looks cool,I just can't see the use of it atm...I mean,I guess attempting oop would be easier with this...

lol yeah.

added to above post

This is actually quite a good idea Nabil! This way, anyone can create a useful precompiler to extend the dbp language and easily use it along with any others. For multiple precompilers, does it just call them in sequence on the same source file?

It would be nice if this displayed the progress and current line number of each parsing step (including precompilers and the compiler). So basically, this should replace the compile progress boxes in ides and provide better progress notification and a way to configure multiple precompilers. Though, i'm not so sure about those tags to add to your code. I think everything should just be configured within the gui of this app.

I'm looking forward to this

yeah...I'd have to say this is about amazing... I like it. It could help alot with people.

@milkman:
well: it uses the temp sourcefile the editor creates and pases along with the project file. this temporary sourcefile (where the editor does the includes) will then be processed by the added PreCompilers (usually), afterwards by the plugins. the PreCompilers can be sorted, the Plugins shouldn't need that.

the plugins will be configured on rightclick and will just have to either "want" or "return" the settings. DBPmC will save 'em. if a PreCompiler wants to support a configuration, it has to be callable without any params since DBPmC runs the executable without parameters to do so. unfortunatly, i cant make it to know if someone has added a configuration mode or not.

the decition is either:
1. just run the exe and hope it closes or opens a config window, which works with all PreCompilers (since they crash or show an error like "cant open project file" and expanding them to show a configuration would just need it to check if a parameter is supplied.
2. check if there is a resource string that says "config" = "param" is defined as "". in that case, configuration would be allowed exclusively for only those files.

i guess i prefer method one. either the programmer of the PreCompiler does support this or doesnt. if their programs crash due to an missing parameter, its their fault anyway, that wouldn't affect DBPmC in executing.

tell me what u think about this.


btw: my development reached version 0.3 a lot of stuff is working now. but the gui handling consumes a lot of work... annoying...

To help standardize things and use precompilers as plugins, i think your manager should treat all precompilers as separate compilers. What i mean by this is that it should just pass them a dbpro file, and expect them to just modify that dbpro file and all its related files. This way, you take the initial input from the ide, copy the project and all its related files to a new directory, and then just call each precompiler in order with the new project file. Finally, you would call the dbp compiler with the project file, and have it create the exe. This is the only good way that i can think of to set something like this up. Precompilers that call the compiler themselves won't work, but how could you use two of them in sequence anyways?

What I will be doing for oodbp is creating a 'core' exe for the precompiler, which just takes a project file as i explained and modifies source files. This will function as a plugin for your manager and hyrichter's ide. On top of that, i will just build my own simple oodbp manager which will actually be called by the ide and then will copy the project files and then call the core exe to modify the code. This would be used if someone did not have a precompiler manager, but still wanted to use oodbp.

EDIT: Also, Nabil, I don't think it is wise to add enum support directly into your precompiler manager. You should probably just create your own plugin precompiler for this, and distribute it with your manager for people to use. This would be better because some people may want to use a different precompiler for enum support, and this would allow them to do that.

Lol: nice. you just told me what i am currently doing.

if you look at the above pic closely, you can see that enum support is done by a plugin.

include file hilighting is disabled and a message shown, if 'PlgIncludesExtention.dll' is not turned on. but still, appending the includes is possible... 'PlgIncludesExtention.dll' is a CORE plugin and will be listed in the plugins list. as is enum support is listed ('PlgEnumeration.dll').

and yes. thats how DBPmC does it. it calles one by one, all listed compilers. since they have to modify the tempsource only, this isn't a big thing.


[text removed . until i have this working, i wont explain how i am doing this. i am very proud of having figured out a way to call them in sequence. anyway if you read the top post closely you can figure out how.]

... so that allows any one to code ther exes just the usual way.

and that makes any precompiler useable with the manager. mind the configuration calling for those exes as stated in the top post (precompiler exe should open configuration if no param is supplied).

Status update:
unfortunatly i have some trouble with the JvPluginManager Delphi component. this renders my 3 finished plugins useless *cry* ... have to work this out.

to anyone doing enums:
use the standart basic style if you implement this functionallity. i have seen some wild things on the forum...
my codebase post: Types and Enums

Why is the configuration feature for plugins needed (when no parameters are passed, defaults to configuration)?

Also, I'm not sure I understand... Your manager does take into account #include files then (i'm not just talking about editor included files)? I mean, does it parse the main source file and create temp #include files so the precompilers can modify those, too?

Anyways, sounds like you've got this pretty much figured out. Nice work so far, can't wait for a demo.

yeah. the include core plugin has an standart option to do include #include's

tell me if i am wrong, but as i know #include's are appended. so this just fits to the other plugin stuff.


for an easier handling, can we agree on renaming and calling the original compiler 'compilerDBP.exe' for example ? would save me a lot of codelines for my manager and anyone elses manager..

PLUGIN: plgDLLCreation.dll
just a note for ppl asking me what will be needed to create a DLL... nothing really final

needed ontop of the code:

What? You mean you've somehow managed to create a precompiler which will allow you to make dlls in dbp?

yep. well ... i am cheating. it states above that the precompiler plugin handles the dll creation since DBP can't. it makes it posible to use any DBP ide to code a plugin at. the syntax is the same, but the final compiler isn't. the plugin takes the information out which is needed to to create a plugin - also the code for plugin creation. that allows the user to code only the needed stuff. everything else is wrapped around and then compiled.
i am still creating a framework where the stuff gets automatically included. i am working allready on the plugin, while DBPmC itself is not yet finished.... stupid me.