Preprocess IF LANG<>"cpp" preventing new targets..
Monkey Forums/Monkey Bug Reports/Preprocess IF LANG<>"cpp" preventing new targets..
| ||
| Hey I don't know if this is really classed as a bug, but there isn't really an alternative forum so: In a lot of the official modules there are things like: Which mean its impossible to write a new target (See http://www.monkeycoder.co.nz/Community/posts.php?topic=4806) without overwriting and maintaining updated versions of that file. With teh current setup monkeymax would have to maintain all of the async .monkey files simply to tweak the preprocess conditions. Seems like a headache to me. Is there a cleaner way to do this, perhaps preprocess vars can be set in the target to specify caps E.g. #FULL_SYSTEM_ACCESS =1 #ADVANCED_SYSTEM = 1 #CPP_LANGUAGE = 1 Or something like that? |
| ||
| Please, take this as a kind suggestion Maybe it could be a good idea to define supported/unsupported flags on a per target basis, so all this could become: #IF TCP_SUPPORTED=False #Error "tcp streams are unavailable on this target" #END If you default any unitialized directive to false, or consider empty directives as false, it would then be enough to define flags where they're supported, instead of hardcoding incompatibilities. #TCP_SUPPORTED=True In ANY target supporting tcp streams. A new target that supports them is added? ok, this flag can be set to true on the target modules or config file. I think this would be much nicer that current approach. |
| ||
| Yeah that would be good! |
| ||
| The problem with this is that it'll generate an 'undefined symbol' error if TCP_SUPPORTED isn't defined somewhere. You can sort of kludge around this with something like: 'MAGIC! Next line is NOP if TCP_SUPPORTED already defined. #TCP_SUPPORTED=False #If TCP_SUPPORTED="0" 'just because... #Error "TCP Not Supported" #Endif But then the issue becomes where exactly is TCP_SUPPORTED defined in the first place? All the TCP code is in native files inside brl/native, there is not really any Monkey code (even in targets) that 'knows' that native TCP code exists. So, it's a tricky one... |
| ||
Ok, here's one possible approach:
Import brl.stream
#If (LANG="cpp" Or LANG="java") And TARGET<>"win8"
Import "native/tcpstream.${LANG}"
#BRL_TCPSTREAM_IMPLEMENTED=True
#Endif
#BRL_TCPSTREAM_IMPLEMENTED=False
#If BRL_TCPSTREAM_IMPLEMENTED="0"
#Error "TCP Streams are unavailable on this target"
#Endif
This effectively provides 'built-in' support for TCPStream for a limited number of targets (ie: the ones I've already done), but also allows for 3rd party targets/modules to import their own native code, as long as they also define BRL_TCPSTREAM_IMPLEMENTED=True. |
| ||
| It looks great to me. |
| ||
| Yeah good thinking! |
| ||
| Ugh, it gets uglier in other areas though...for now, the easiest way to deal with this is probably just to remove the 'unavailable on this target' checks from several brl modules...will have a think about it. |
| ||
| Could you just make it so the undefined vars default to "" instead of being undefined... You are checking if it exists In order to error, so is it a small step to default a value instead? No scrap that wouldn't work! |
| ||
| It is quite nice with an explainable error message. What about 2 simple commands? 1. A module do not know if there another module that implements native code for it's classes/functions/globals/consts 2. A module that has classes/functions/globals/consts with extern links knows that and can define it uses "something" external. Ex Inside tcpstream.monkey: #DefineInterface TCP_STREAM Imports is traversed to get more dependencies like mojo.graphics that would set #DefineInterface MOJO_GRAPHICS if that was also an import with external dependencies. 3. Each "native" file import knows what targets it implements. #If (LANG="cpp" Or LANG="java") And TARGET<>"win8" Import "native/tcpstream.${LANG}" #ImplementInterface TCP_STREAM #Endif 4. Someone makes an implementation of win8 tcpStreams #If TARGET = "win8" Import "tcpstream.cpp" #ImplementInterface TCP_STREAM #Endif If a target contains module implementations (like bmx does for mojo) then TARGET.MONKEY can have #ImplementInterface TCP_STREAM #ImplementInterface MOJO_GRAPHICS #ImplementInterface MOJO_AUDIO or have this in each bmx_mojo module Check is done in trans that any define matches one implement The error would be: "No dependancy found for TCP_STREAM on target playstation3" (if Define found but no Implement ) Or if brl folder is removed: "Found TCP_STREAM implementation on target playstation3, but no TCP_STREAM interface was defined" (if implement found but no define) If 2 Implement found "Found 2 TCP_STREAM implementations for win8, you can only have one" The user can always add #DependencyImplemented TCP_STREAM to remove error message from their code if they know what they are doing. Or does that complicate things even further? |
| ||
| Sounds good! Might be confusion of using "implement" and "interface" as keywords when they are already used elsewhere in monkey. How about something simplified along the lines of #Uses and #Requires ? mojo.monkey #Requires MOJO_GRAPHICS #Requires MOJO_AUDIO target_name/template/CONFIG.monkey #Uses MOJO_GRAPHICS #Uses MOJO_AUDIO |
| ||
| Yeah that was very elegant, I like it :) |
| ||
| > How about something simplified along the lines of #Uses and #Requires ? Not bad! Not sure if I like #Uses though - too much like #Requires. How about #Provides instead? I'm also not quite convinced this is really necessary in the first place if the preprocessor can deal with this (if a little more long-windedly) as-is (or perhaps with some minor cleanups!). I'll keep thinking this one over, but brl modules at least should be more expandable next release. |
| ||
| Oh yeah #Provides works! W00t! Well anyyways once the next releases drops down I will finish off porting some of the walled-off modules to monkeymax :D. Yeah it's doable in current preprocess but I guess doing it this way would streamline the approach and makes it more userfriendly. |
   |