Is it possible to add #defines in BMax?

BlitzMax Forums/BlitzMax Programming/Is it possible to add #defines in BMax?

JaviCervera

(Posted 2006) [#1]

When you compile C/C++ files, it is a common thing that you can change some preprocessor definitions to change how the files are compiled. For example, a common example is that a library is compiled as a dll, but if you define some macro (lets say, for example, STATIC_LIB), it is compiled as a static library.

These macros are usually defined in the project settings from your C++ IDE. How can I define them when I am compiling the C++ files from within a .bmx file? I mean, imagine I have a C++ library that I want to turn into a BMax module. I create a .bmx file which imports all the C++ files and declares the functions contained in them for use with BMax. How can I define macros there so the C++ compiler takes them into account when compiling the files?

Someting like:

Import "-DSTATIC_LIB"

Dreamora

(Posted 2006) [#2]

What do you actually want to achieve?
*I try to understand what your target is, because compiler flags are useless as only .o files are generated to be linked by with the BMX -> .o files and thats done by the BM defined flags, not anything else that could break it*

Or are you more asking how to use macros defined in C / C++ within BM. The answer to that would be: you can't.
Only functions, Structs, Classes (and perhaps variables, don't know)

Chris C

(Posted 2006) [#3]

I love compiler flags, for example certain parts of ode require a lower optimisation -o1 and max seems to always use -o2 with no way to specify anything different

Manybe a compiler type (not usable at run time)

gcc.o=1
import "oddcode.cxx"
gcc.o=2

maybe even
gcc.D=STATIC_LIB

so basically the . becomes a - D is the option and the = is dropped (but used for readability)

This would allow only imported code to have its options changed and bcc could continue to use whatever options it chooses for the bmx files

being that ms compilers >7.1 can't create dll's that use other dll's without side by side dll hell, isnt it time to look again at the rather odd embargo on dll creation?