-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Wish: Conditional Compilation
- Thread starter splatt
- Start date
- Similar Threads Similar Threads
Good fearure request. For those familiar with conditional compiling what are your thoughts on how it should be implemented?
I propose the use of # to mark out code for conditional compiling:
I propose the use of # to mark out code for conditional compiling:
B4X:
#If DEMO = True Then
DoThis()
#Else
DoThat()
#End If
Yes, but there's a problem using conditional compilation to create lite/full, paid/free versions: that is the code is inside a b4a project. That project has a name. A single package name. Both versions that you compile will need their own unique name. Which means you'll have to change the package name each time you compile. Forget one time and you'll cripple the full apk, making market customers unhappy, or extend the free version.
In another thread, Erel suggested using a boolean value to control how the app behaved; whether free or paid, but cautioned the full vision code would be in the free/trial app.
My solution was to have a shared code module accessed by two skeleton activity code files in two projects. Then the code that makes the lite version lite, or the full version full, would be placed in the relevant projects activity module, thus keeping the two totally separate. But again Erel reminded me that code modules cannot be accessed by other projects.
@Erel, can a code modules .bas file be placed one folder up in the folder that contains the two project folders?
In another thread, Erel suggested using a boolean value to control how the app behaved; whether free or paid, but cautioned the full vision code would be in the free/trial app.
My solution was to have a shared code module accessed by two skeleton activity code files in two projects. Then the code that makes the lite version lite, or the full version full, would be placed in the relevant projects activity module, thus keeping the two totally separate. But again Erel reminded me that code modules cannot be accessed by other projects.
@Erel, can a code modules .bas file be placed one folder up in the folder that contains the two project folders?
Last edited:
I really would like this, too
About the differentiation between Pro and Lite/Demo versions which would need different package name: One option would be to use the package name itself as possible condition. That way you first set the package name, then compile and everything is fine.
Or, even better: Allow a editor option for different versions to be compiled, and handle the package name automatically.
BTW: Back from B4PPC, now really enjyoing B4A
About the differentiation between Pro and Lite/Demo versions which would need different package name: One option would be to use the package name itself as possible condition. That way you first set the package name, then compile and everything is fine.
Or, even better: Allow a editor option for different versions to be compiled, and handle the package name automatically.
BTW: Back from B4PPC, now really enjyoing B4A
I'm just reviving this old request. I really would like to see something like this. I think it could be done in a way that the package name, icon, code, etc. can all be conditional. B4A would just have to process this stuff "first", then ignore it when actually compiling the app.
While it's nice that we can edit some of the app attributes at the special section in the beginning of the "main" module, this has actually somewhat made things more difficult depending on the situation.
For example, I do share the same code for free/paid versions and use a boolean to toggle them when compiling. To be accessible from all modules, that boolean is declared and set in a "common" code module. So now when I compile my project (free & pro, each for Google and Amazon... 4 times) I need to confirm the following:
1) Go to Project menu to change/confirm the package name
2) Go to Common module to change/confirm the free/pro boolean, Amazon/Google variable, and version number(version string to access in the app)
3) Go to Main module to change/confirm the app and label and version code/number.
This is a lot of bouncing around. If we can't have conditional compile, I would almost like to see it all consolidated into one option window like what was also brought up a while back, but that was before some of the app's settings were moved to the Main module.
Some other thoughts: How about several pre-defined variables and booleans that are somewhat built into B4A that we can define the values of in one "options" screen in the IDE and access their values in our code?
Such as these in a settings window (where the brackets are a text field where user can enter a value):
MyApp.PackageName [com.my.package]
MyApp.AppLabel [My App Name]
MyApp.VersionCode [51]
MyApp.VersionString [v3.5.1]
MyApp.CustomString (1) [Amazon]
MyApp.CustomString (2) [ ]
MyApp.CustomString (3) [ ]
MyApp.CustomString (4) [ ]
MyApp.CustomString (5) [ ]
MyApp.CustomBoolean (1) [True]
MyApp.CustomBoolean (2) [False]
MyApp.CustomBoolean (3) [False]
MyApp.CustomBoolean (4) [False]
MyApp.CustomBoolean (5) [False]
Then in the code....
I'd prefer conditional compile but I'd be happy with something like this for now... where we can at least consolidate all of the different things related to our app's version, market destination, etc. could be handled in one place.
Any thoughts?
While it's nice that we can edit some of the app attributes at the special section in the beginning of the "main" module, this has actually somewhat made things more difficult depending on the situation.
For example, I do share the same code for free/paid versions and use a boolean to toggle them when compiling. To be accessible from all modules, that boolean is declared and set in a "common" code module. So now when I compile my project (free & pro, each for Google and Amazon... 4 times) I need to confirm the following:
1) Go to Project menu to change/confirm the package name
2) Go to Common module to change/confirm the free/pro boolean, Amazon/Google variable, and version number(version string to access in the app)
3) Go to Main module to change/confirm the app and label and version code/number.
This is a lot of bouncing around. If we can't have conditional compile, I would almost like to see it all consolidated into one option window like what was also brought up a while back, but that was before some of the app's settings were moved to the Main module.
Some other thoughts: How about several pre-defined variables and booleans that are somewhat built into B4A that we can define the values of in one "options" screen in the IDE and access their values in our code?
Such as these in a settings window (where the brackets are a text field where user can enter a value):
MyApp.PackageName [com.my.package]
MyApp.AppLabel [My App Name]
MyApp.VersionCode [51]
MyApp.VersionString [v3.5.1]
MyApp.CustomString (1) [Amazon]
MyApp.CustomString (2) [ ]
MyApp.CustomString (3) [ ]
MyApp.CustomString (4) [ ]
MyApp.CustomString (5) [ ]
MyApp.CustomBoolean (1) [True]
MyApp.CustomBoolean (2) [False]
MyApp.CustomBoolean (3) [False]
MyApp.CustomBoolean (4) [False]
MyApp.CustomBoolean (5) [False]
Then in the code....
B4X:
'(Main Module)
#ApplicationLabel: MyApp.AppLabel
#VersionCode: MyApp.VersionCode
#VersionName: MyApp.VersionString
#PackageName: MyApp.PackageName <---- This does not currently exist... package name cannot be defined in the main module.
'(Common Module)
Dim ThisAppIsProVersion as Boolean = MyApp.CustomBoolean (1)
Dim ThisAppMarketVersion as String = MyApp.CustomString (1)I'd prefer conditional compile but I'd be happy with something like this for now... where we can at least consolidate all of the different things related to our app's version, market destination, etc. could be handled in one place.
Any thoughts?
I don't see how a UI page for these settings will be more convenient.
The package name cannot be set as an attribute due to various tasks that run in the background.
You can get the relevant attributes values in your code with PackageManager.
The package name cannot be set as an attribute due to various tasks that run in the background.
You can get the relevant attributes values in your code with PackageManager.
Hello,
I am going to resurrect the wish for conditional compilation from this fairly old thread. I feel conditional compilation would be a very important addition to B4A. Once again I'm at the point in a project where I need conditional compilation – otherwise I will need to split the project into two separate projects.
As mentioned above creating a Boolean variable really doesn't work – the package name won't be changed, and the skipped code will be present in all versions. Creating shared code and initial code modules works in some cases, but I find I need small changes scattered throughout most of the code making this approach not workable.
Conditional compilation would have to apply throughout the compilation process. The .B4A as well as all included .bas modules would need to be included in the process as well as the Package Name, App Icon, probably the Manifest, and I'm sure several other things I'm not aware of. Adding conditional compilation to B4A, I'm sure, would be difficult.
As Erel stated earlier in this thread "Note that Java doesn't support conditional compilation by design." This is probably for a very good reason.
One IDE I have used in the past, I think it was probably Delphi, had a Text entry field in what would be the Project Menu in B4A that allowed constants to be "defined" by simply adding the space separated text to the field (XXX YYY ZZZ). You could then use "#IFDEF YYY ... #ELSE ... #ENDIF" anywhere in the source code or included units. This was a very handy implementation.
I hope conditional compilation will be considered for B4A. I think it would be a huge feature.
Barry.
I am going to resurrect the wish for conditional compilation from this fairly old thread. I feel conditional compilation would be a very important addition to B4A. Once again I'm at the point in a project where I need conditional compilation – otherwise I will need to split the project into two separate projects.
As mentioned above creating a Boolean variable really doesn't work – the package name won't be changed, and the skipped code will be present in all versions. Creating shared code and initial code modules works in some cases, but I find I need small changes scattered throughout most of the code making this approach not workable.
Conditional compilation would have to apply throughout the compilation process. The .B4A as well as all included .bas modules would need to be included in the process as well as the Package Name, App Icon, probably the Manifest, and I'm sure several other things I'm not aware of. Adding conditional compilation to B4A, I'm sure, would be difficult.
As Erel stated earlier in this thread "Note that Java doesn't support conditional compilation by design." This is probably for a very good reason.
One IDE I have used in the past, I think it was probably Delphi, had a Text entry field in what would be the Project Menu in B4A that allowed constants to be "defined" by simply adding the space separated text to the field (XXX YYY ZZZ). You could then use "#IFDEF YYY ... #ELSE ... #ENDIF" anywhere in the source code or included units. This was a very handy implementation.
I hope conditional compilation will be considered for B4A. I think it would be a huge feature.
Barry.
Last edited:
Thanks for your reply.
I'm happy to hear that conditional compilation is on the horizon.
Maybe this is obvious, but as I am finishing up the project I alluded to above, I realize that conditional compilation would have to apply to the output (Objects) directory also.
Using my scenario mentioned above of having a list of text "defines" within the Project menu of B4A, the list of "defines" could be appended to the name of the Objects directory. No defines, nothing appended. If the defines are kept within reason, it would not be too bad.
In practice, in the past, I've only used one or two defines at a time. You may end up with an output directory similar to the name "Objects tst rel". This is not too terrible and would differentiate the output APK, manifest, and icon.
Just a thought.
Barry.
I'm happy to hear that conditional compilation is on the horizon.
Maybe this is obvious, but as I am finishing up the project I alluded to above, I realize that conditional compilation would have to apply to the output (Objects) directory also.
Using my scenario mentioned above of having a list of text "defines" within the Project menu of B4A, the list of "defines" could be appended to the name of the Objects directory. No defines, nothing appended. If the defines are kept within reason, it would not be too bad.
In practice, in the past, I've only used one or two defines at a time. You may end up with an output directory similar to the name "Objects tst rel". This is not too terrible and would differentiate the output APK, manifest, and icon.
Just a thought.
Barry.
Yes Delphi's offered conditional compilation for a very long time. As I see it conditional compilation will necessary if we want to every be able to share code in cross platform situations. I.e. b4a, b4j and possibly b4i.