I want to build a cross-platform library for generating images of certain type (e.g. retail receipts). As I get it, the only library that supports working with images and font drawing in Haxe universe is OpenFL. The question is the following - is it possible to create an OpenFL project that compiles to library? Or at least generates sources to be used as linked library? By default OpenFL generates an executable application which is not appropriate to me.
Target platforms are iOS and Android, i.e. C++ target should work for me.
As far as I know, you just create a standard haxe library and declare openfl as a dependency.
Take a look at some of the libs on haxelib for an example..
I believe this is what Lime is for.
Lime is actually part of the OpenFL project, but it's lower-level than OpenFL itself. It was split off from the main project in response to people who wanted to use some of OpenFL's tools without it automatically opening a window.
Lime recently added asset support, so it should work for your purposes.
Related
The Android app I am working on is completely written in C++. I need to integrate it with a static library that also is written in C++. There is no dependency on STL in any of the projects.
The static library uses cmake to build. Unfortunately, the app is based on an old AOSP version of Android NDK and has no support for cmake.
I also have a newer version of Android NDK in a different directory. This version does support cmake toolchains.
I am thinking I will build the static library against the new NDK and use it in my main project. The ABI is the same for both the projects - armv7a.
I have tested this logic with a sample code. It seems to work. I am able to invoke methods in the static library from my main app.
Also, there are no name-mangling issues.
The question I have is if there is any issue I am overlooking.
I am thinking it should not matter that the compilers used to build the sources are different. As long as they are producing arm-compatible code, I should be able to able to integrate them.
As a matter of fact, another library that I am using, gstreamer, is available for download as pre-built binaries at https://gstreamer.freedesktop.org/data/pkg/android.
Please advice.
For those interested, mixing NDKs doesn't seem to be an issue as long as you follow certain guidelines. Some of them are listed at https://developer.android.com/ndk/guides/cpp-support.
Essentially, there is no problem if your project is 'C' based. However, if you are using C++, you must not use STL.
I have managed to build part of my code with two NDKs and I am not seeing any link time or runtime errors.
I created a haxe project using openfl. I can build and run the project on my own desktop using lime test windows.
Now how do I actually ship this project to other users?
I tried simply zipping the binary output created by running the command above. When I then unpack this zip on a different computer and start the executable file it will complain that I'm missing certain .dll files (more specifically the libstdc++-6.dll file).
Although this is not a direct answer to your question, a solution to this issue would be to compile through another software/tool, such as FlashDevelop.
For a few versions already, FlashDevelop includes an App manager feature that allows you to easily install the latest versions of Haxe, Lime & OpenFl (in an all-in-one package), and compile for all the Haxe/Lime/OpenFl targets seamlessly by just switching a value in a drop-down menu.
This allowed me to compile without any problems native C++ or Neko versions of my projects, thus embedding all the necessary files that could be zipped and sent to other computers.
I'm working on WinRt version of my class library dll. Finally, after the huge "code cleanup" my project is on building step and I have two ways. To build the solution with Release|AnyCPU as usually or build it with Release|ARM (Which unclear for me). Which dependencies my dll will get or avoid in process of building, what will be different, will there a specific IL optimizations on a second way?
If you're only using managed code, there's no reason not to use Release|AnyCPU. This way the same package will be used for all three platforms (ARM, x86 and x64).
On the other hand, if your project references natively compiled library, you'll need to set a specific platform, like Release|ARM, that your native library is compiled for. If the native library is installed as an extension (e.g. SQLite for Windows Runtime), you'll be able to compile your app for all 3 target platforms, each one referencing the appropriate native library, though they will need to be individual packages instead of a single universal one.
You'll still be able to submit your app to the store as a single app even if it has 3 separate packages, one for each platform.
I want to compile a tiny actionscript file. Is there something out there that exists and works?
I tried compiling and installing swftools without success. I also read about Flex SDK on all other posts. However all links are either broken or outdated. Seems like there isn't a package for Linux?
The easiest way to compile and test out ActionScript is to use Wonderfl. It is a web-based Flash IDE that will compile ActionScript and allow you to view and download the resulting SWF.
To develop on your own machine, you can use the Flex SDK, which can be downloaded from Adobe Open Source. This includes mxmlc, the command-line ActionScript compiler. You can find more information on using mxmlc in the Flex documentation. You could also try FB4Linux, a project that ports the Flash Builder IDE to Linux.
checkout redbean
http://redtamarin.com/tools/redbean
it is a command line tool written in AS3 that reuse the asc.jar
to compile AS3 to ABC (ActionScript ByteCode)
download the redtamarin SDK
http://download.redtamarin.com/
it will gives you redshell, redbean, etc. for Linux
alternatively you can also install as3shebang
which will allow you to run AS3 as shell scripts
https://github.com/Corsaair/as3shebang
Monotouch compiles the app into the native code. How can Apple know that the app was built using MonoTouch? Does Monotouch leaves a signature in the application?
Does Monotouch has its own libraries which could be a trace of the origin or it compiles all the code and all its .NET libraries into native code?
The resulting .app package contains the application binary, your resources as well as the required additional libraries, such as:
montouch.dll;
System.dll;
System.Xml.dll and so on.
As such, it would be trivial for them to check if the application was built with monotouch or not - it is as simple as right clicking the package and then select "Show package contents" in Finder.
However, you need not worry about that, as Apple has just relaxed their License Agreement: http://daringfireball.net/2010/09/app_store_guidelines
And even if the assemblies containing metadata were not included in the app bundle (directory), I am quite sure it is relatively trivial to learn how to recognize from the patterns in the actual code in the app executable that it was produced by MonoTouch, if one would want to. So there is not reason for MonoTouch to try to "hide" that fact.