Dynamically compiling AIR apps - air

I've been searching for a way to dynamically compile AIR apps on the go.
Specifically, I'd need the title of the program and a couple variables changed on compile. I'll be creating hundreds, if not thousands, of versions of what is essentially the same program so I'd like to avoid doing it by hand :)
Is this possible with AIR? If not, could I do it with something like Java?

Yes, this is possible using the mxml compiler in the Flex sdk. It requires some knowledge of a build tool like ant or maven.
Automate the build process with apache ant or maven.
Use Actionscript compiler directives to define place holders for your variable data in your code.
Modify the build scripts to compile the build, and pass in the variable data as compiler arguments
I've done this with ant build scripts to include a timestamp and other info in the app's version string. Here's example with a timestamp...
1. Define variables in the compiler argument options for your project
The syntax is:
-define=NAMESPACE::VARIABLE_NAME,'variableValue'
For example:
-define=APPDATA::TIMESTAMP,"xxx"
This is what a developer would put in their IDE. When they compile their apps, the version string will have "xxx" in it. When the automated build script compiles the app, it passes in an actual timestamp using a similar argument.
2. Reference the variable in your code.
I'm using it as a String, but you can do Boolean and I assume the other primitive types.
public var appVersion:String = "MyApp " + APPDATA::TIMESTAMP;
You can conditionally compile code into the SWF with booleans:
-define=CONFIG::DEBUG,true
Now wrap code blocks with this compiler directive, and if true it will be compiled into the swf:
public function something():int
{
var a:int = 1;
CONFIG::DEBUG
{
a=2;
}
return a;
}
While this is pretty handy, I recommend only using compiler directives for things you really need to do at compile time, and not for general configuration :)
Resources:
Using conditional compilation
mxmlc compiler options
flex ant tasks
flex mojos maven plugins

Related

Can nw addon be built with _HAS_ITERATOR_DEBUGGING=1 for debug mode? (Windows)

Original questin: Is there any way to get what macros nw-gyp add to the build project by default?
I'm developing a nw addon and I've tried to link a custom static lib to .node DLL. However I found nw-gyp will add _HAS_ITERATOR_DEBUGGING=0 by default (It always appends to the addon project to override custom defines), which will affect the actual structure size for STL types (e.g. std::string).
So is there a way to get such macros node gyp added by default, or is there an easy way to make compiler's (maybe the whole toolchain, link tool etc.) configuration for both static lib and nw build project the same?
Now I've add _HAS_ITERATOR_DEBUGGING=0 to my lib and make it MT(D), and It seems to work fine, but I'm not sure if this is the right way. (Some other compiler settings may not cause compilation error but can crash in runtime)
Edit: Share some analysis to make my origin question clearer.
All current question is on Windows platform.
The _HAS_ITERATOR_DEBUGGING=0 is added even when I build nw addon in debug mode (with --debug), and this may be affected by the nw headers downloaded by nw-gyp. For example, headers download from http://node-webkit.s3.amazonaws.com/v0.49.2/nw-headers-v0.49.2.tar.gz , you will find 'defines': [ 'DEBUG', '_DEBUG', 'V8_ENABLE_CHECKS', '_HAS_ITERATOR_DEBUGGING=0' ] in common.gypi at line 288 in Debug_Base config section, and this is most likely inherit from https://github.com/nwjs/chromium.src (I guess here https://github.com/nwjs/chromium.src/blob/nw60/build/config/BUILD.gn#L130). So can it be concluded that Chrome add these defines for debug mode on purpose?
What is the problem _HAS_ITERATOR_DEBUGGING=0 in debug for me? Well, it affects the size for many STL classes (std::string, std::vector and etc.). So all debug lib that need to be linked to nw addon should be compiled with '_HAS_ITERATOR_DEBUGGING=0', otherwise compilation error will occur for static libs and runtime pointer problem crash (struct offset mismatch) for dynamic libs (of course it is not a good practice to use STL in dynamic lib headers, but if you can assume the toolchain same it will still work fine). But this is really hard for me when it comes to third-party binaries, I've got no sources for most of them, so I can't give a debug static lib with _HAS_ITERATOR_DEBUGGING=0 on. This is really frustrating when I need to debug the addon with lldb or VS, since all variables are optimized and you cannot debug their values.
Can I force _HAS_ITERATOR_DEBUGGING=1 for debug mode? As mentioned in origin question, it cannot be done normally like answer from #mmomtchev. A hack way to do is to add "/D _HAS_ITERATOR_DEBUGGING=1" to configurations->Debug->msvs_settings->VCLinkerTool->AdditionalOptions in gyp file for addon, this will append /D _HAS_ITERATOR_DEBUGGING=1 to the end of the compile command which override the former defination. But I'm not sure if this is a good workaround! I've checked v8 header files and have found some classes with std::string and std::vector members. I think force _HAS_ITERATOR_DEBUGGING will cause some problem if you use these classes, but for other classes it is safe (I've tested many cases, normal classes like v8::value v8::function work well). And it is not safe when cooperating with other addons. Let's assume one debug addon A and another release addon B need to communicate with each other, they agree on one C++ struct for data exchange. A common way is to let A to wrap a C++ struct instance to a JS object for user. and let user pass the JS object to B by calling methods provided by B (the JS object is one of the arguments), and then B unwrap the JS object from arguments and get the pointer of the C++ struct instance. All looks fine, but what if the C++ struct has std::string member? The sizes of same C++ struct for A and B are not the same. so B will crash when trying to access the member with type of std::string or std::vector. This is not an issue if _HAS_ITERATOR_DEBUGGING=0 is set for debug mode since _HAS_ITERATOR_DEBUGGING is always disabled for release, and I guess that's why nw addon can work with mixed production mode(debug an release) addons in common cases.
So my final question is: If it is not a good way to force _HAS_ITERATOR_DEBUGGING=1 for debug and I don't have source code for many external compiled lib binaries, does it mean I've no way to build a nw addon in debug mode? Athother possible way is to wrapper those libs with C style API and compile them to dynamic libs, but this is really huge work for me and is unacceptable.
Normally, _HAS_ITERATOR_DEBUGGING=0 is defined by default on all Release builds.
If you need to add macros, you need to add this section to the root of your gyp:
'defines': [ '_HAS_ITERATOR_DEBUGGING=0' ]

Kotlin/Native How to use a header-only C/C++ library

So I'm trying to use stb_image in my Kotlin/Native project and I am having trouble trying to include it in my project. It's a header only library and konan seems to expect a compiled object file anyways so I was wondering if there is any way of just generating the cstubs and then using the header for linking unless I have to compile a basic translation file since stb_image only requires you to have a translation unit that defines STB_IMAGE_IMPLEMENTATION however I have that defined in my compilerOpts -GSTB_IMAGE_IMPLEMENTATION. Would it be easier to just compile a translation unit, create the static object, and then link against it or does K/N have some way of doing that for me?
I am using Gradle Multiplatform so if there is some gradle script I can run then please let me know.
My -GSTB_IMAGE_IMPLEMENTATION is supposed to be -DSTB_IMAGE_IMPLEMENTATION and I needed to put my -I switch in my compilerOpts not linkerOpts.
I recommend actually creating a translation file but it's not required.
You can just give the header file with the compileropts as you've done and that should work.
You can look at this as a reference. I'm working on a wrapper in my free time.

Kotlin kapt: generating code through annotation processors: cannot find symbol (of generated classes) in stubs

I have a module with annotation processor which generates quite lot of classes I use throughout the project.
I used that module in one of my projects, though it was hell to make it work properly, it works as expected - I run build, it generates classes and everything's fine.
In new project, I use the same module (just copied code), the same config etc. but if I run build, in stubs it replaces all my "to be generated classes" references as Class<Any>, and build fails.
Workaround is that I use kaptKotlin task separately:
it generates code, and than I have to build again (kapt again is run there but no errors thrown) and only than it works.
But even in kaptKotlin task I get lot's of e: cannot find symbol in generated stubs (though code is generated).
I think that while running that tasks those should be ignored or something.
How can I correct that behavior?
Or how can I make it work through single "build" task, so kapt would in stubs reference "to be generated code" correctly and not replacing with Class<Any>?
P.S. using latest versions of Kotlin. Tried correctErrorTypes = true - no success.

How to run the sha2.c of polarssl

I was trying to use the sha2.c file from polarssl at this link,
https://polarssl.org/sha-256-source-code
I am actually quite a newbie to this, but I was able to get this on Eclipse and when I tried to build it, it gives the error
c:/mingw/x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text+0x3d): undefined reference to `WinMain'
do I have to pass some kind of data in the arguments? how can I find out how to use it?
The problem is not in the source file you downloaded, but the fact that you need to make 'an application'. Eclipse cannot compile 'just some functionality' unless you instruct it to build a library. You will have to provide a WinMain / main function so that Windows knows what to do when you start the application.
That is what the compiler is complaining about, there is no main() functions it can compile into the application!
Easiest way to start is to start a Generic C Application in Eclipse and then add this sha2 source file and header to that project. The Generic C application project already has a main function you can work from..

How can I create a single Clojure source file which can be safely used as a script and a library without AOT compilation?

I’ve spent some time researching this and though I’ve found some relevant info,
Here’s what I’ve found:
SO question: “What is the clojure equivalent of the Python idiom if __name__ == '__main__'?”
Some techniques at RosettaCode
A few discussions in the Cojure Google Group — most from 2009
but none of them have answered the question satisfactorily.
My Clojure source code file defines a namespace and a bunch of functions. There’s also a function which I want to be invoked when the source file is run as a script, but never when it’s imported as a library.
So: now that it’s 2012, is there a way to do this yet, without AOT compilation? If so, please enlighten me!
I'm assuming by run as a script you mean via clojure.main as follows:
java -cp clojure.jar clojure.main /path/to/myscript.clj
If so then there is a simple technique: put all the library functions in a separate namespace like mylibrary.clj. Then myscript.clj can use/require this library, as can your other code. But the specific functions in myscript.clj will only get called when it is run as a script.
As a bonus, this also gives you a good project structure, as you don't want script-specific code mixed in with your general library functions.
EDIT:
I don't think there is a robust within Clojure itself way to determine whether a single file was launched as a script or loaded as a library - from Clojure's perspective, there is no difference between the two (it all gets loaded in the same way via Compiler.load(...) in the Clojure source for anyone interested).
Options if you really want to detect the manner of the launch:
Write a main class in Java which sets a static flag then launched the Clojure script. You can easily test this flag from Clojure.
Use AOT compilation to implement a Clojure main class which sets a flag
Use *command-line-args* to indicate script usage. You'll need to pass an extra parameter like "script" on the command line.
Use a platform-specific method to determine the command line (e.g. from the environment variables in Windows)
Use the --eval option in the clojure.main command line to load your clj file and launch a specific function that represents your script. This function can then set a script-specific flag if needed
Use one of the methods for detecting the Java main class at runtime
I’ve come up with an approach which, while deeply flawed, seems to work.
I identify which namespaces are known when my program is running as a script. Then I can compare that number to the number of namespaces known at runtime. The idea is that if the file is being used as a lib, there should be at least one more namespace present than in the script case.
Of course, this is extremely hacky and brittle, but it does seem to work:
(defn running-as-script
"This is hacky and brittle but it seems to work. I’d love a better
way to do this; see http://stackoverflow.com/q/9027265"
[]
(let
[known-namespaces
#{"clojure.set"
"user"
"clojure.main"
"clj-time.format"
"clojure.core"
"rollup"
"clj-time.core"
"clojure.java.io"
"clojure.string"
"clojure.core.protocols"}]
(= (count (all-ns)) (count known-namespaces))))
This might be helpful: the github project lein-oneoff describes itself as "dependency management for one-off, single-file clojure programs."
This lets you define everything in one file, but you do need the oneoff plugin installed in order to run it from the command line.