Is it possible / planned to build a Win/Mac/Linux package from within one platform?
An IDE called RunRev LiveCode allows to deploy to multiple platforms, but it supports only HyperCard language, afaik it's also possible in Qt
a Zotero Standalone Builder can be used to bundle Webapp XUL Wrapper into distributable bundles for Mac, Windows, and Linux
would it be possible to use it with TideSDK?
a Kickstarter project starts for AppJS, the maintainers want to launch a cloud service to deploy the app for all platforms in the cloud and then just download the exe, dmg or a linux package
It is not possible to build apps on the same platform with TideSDK. A service platform is coming that will solve this issue to make development easier for everyone. We'll make announcements with this available.
Related
I have a medium sized C/C++ Qt application that uses some win32 API functions. I compiled for release and created a directory that contains all the needed DLLs and resources files needed. I tested it on other machines and it works fine.
Now my question is.. how to package such application so that I can put it on microsoft store? Note that it is not a UWP app and it uses some functions from win32.
You can use the Professional edition of Advanced Installer (it has Visual Studio integration) and create an MSIX package ready for the Windows Store.
Here is an article that takes you through the MS Store publishing steps
Also, an article that explains how to build and MSIX package using Advanced Installer's VS extension
Disclaimer. I work on the team building Advanced Installer.
I understand that there is no NaCl SDK support for ARM platform so far. I am right now developing applications for ARM on Ubuntu. Is there a way I can test the applications on ARM machines without using SDK?. As far as I understand from Native Client website, we need SDK to start the server to test the applications. Does any one have experience on this?
You can develop your application on an x86 machine, and use the SDK's compilers to target NaCl ARM. This is commonly called cross-compiling. You then copy files over to the ARM machine that you want to test with, or use QEMU (to emulate ARM's ISA on an x86 machine).
It's possible to build a NaCl SDK from source for ARM, it's simply not distributed by the SDK team because there hasn't been demand for this.
You're trying to test in a browser? The server is there to serve content to a browser, but I've often found it simpler to use python -m SimpleHTTPServer.
I am developing a for an embedded target using buildroot, adding our custom applications as new packages.
These packages depend on some non standard libraries(which we already integrated into buildroot) that are painful to install natively on the development workstations. Can I use buildroot out-of-tree builds to compile the applications for my development machines to test them as well? Assuming all the libraries are in place, they are generic linux applications that should not have problem running on PCs.
Is there a more convenient way to manage both builds?
The only supported way is to use a "crosscompiler" for your host system.
See buildroot environment with host toolchain
I just have a little question about running Qt created apps on different operating systems.
As a normal user do i have to install Qt framework to run Qt apps ?
I mean i've created Qt app using Windows , then i made a build for Linux .
Do i need to install the Qt framework on the Linux pc inorder to run that app ?
Or there is a way to package all the needed libraries into the app installer .
Best Regards
You can deliver the dynamic libs you need with your application, as it's described here:
http://doc.qt.io/qt-5/deployment.html
Since Qt is not a system library, it has to be redistributed along
with your application; the minimum is to redistribute the run-time of
the libraries used by the application. Using static linking, however,
the Qt run-time is compiled into the executable.
Depends what you mean by 'framework', you will need the runtime libraries, unless you paid Nokia for a license to allow static linking.
For Linux, I think you would generally ensure that the Qt packages have been installed during installation (i.e. make them a requirement of the package you provide). Under Mac OS you would need to package the .so (shared objects) with your application. Under Windows you do the same (provide the .dlls) and install them with the application (not in the system folders).
The issue with static linking that #cbamber85 is alluding to, is the conformance with the LGPL licence where it's legal to link to the libraries at runtime but not at compile time (i.e. use the .so/.dll but not the .a files).
I am writing a program that has an AIR front-end, but a back-end written in another language (Python, in this case). Since AIR can't invoke other executables, the relationship has to be the other way around, with Python running an AIR subprocess. How can I locate the user's AIR runtime? I'd like to be able to do this on Mac, Windows, and Linux.
(Ironically, this would be super easy if I could package the AIR debug runtime, but the licensing agreement requires that the user download the regular runtime themselves and run the installer.)
First, you can get a (free) licenses to redistribute the AIR runtime installed:
See:
http://www.mikechambers.com/blog/2008/04/07/redistributing-the-adobe-air-runtime-installer/
and
http://www.adobe.com/products/air/runtime_distribution1.html#license
As far as launching an AIR application, you can launch it like any other native applications (since the AIR app is just a native app once it is installed).
As far as finding where the user installed the app, at least on Windows, I believe you can get the info programatically from the registry, based on on the appid of the AIR app you want to launch.
Finally, you can find a proof of concept on this here:
http://www.mikechambers.com/blog/2008/01/17/commandproxy-net-air-integration-proof-of-concept/
and
http://www.mikechambers.com/blog/2008/01/22/commandproxy-its-cool-but-is-it-a-good-idea/
mike