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
Related
Feels like a silly question, but I'm struggling to find the answer online: Is it possible to deploy Qt apps to Windows if you did development on a Linux machine? It seems the answer should be "yes", but I can't seem to use windeployqt on my linux machine.
If it is possible, what additional resources do I need to do this?
Yes, it's of course possible.
You have to cross-compile Qt using the MinGW compiler, targeting Windows.
You'll have to patch and build windeployqt yourself. By default, windeployqt is looking for g++.exe in the path. Of course this makes no sense on a linux build host, so you'd have to tweak it so that it finds the correct compiler and runtime libraries.
You can then build your application using the cross-targeted Qt build, and deploy all the necessary artifacts into some deploy folder using windeployqt.
To package the deployed build, you can run nsis or wix on Linux as well, to obtain a Windows installer. You can even sign the executable files (required these days for Windows), there's an open source tool called osslsigncode - it works on most platforms and doesn't require Windows.
It'll take a bit of time for you to figure it all out. It's certainly easiest to just build on Windows and not mess with it. But if you insist on building on Linux - you certainly can.
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.
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.
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'm wondering about best practices to develop ASP.NET MVC apps with an option to deploy on Linux. If you are creating these kinds of MVC apps,
What Linux/Mono platform are you targeting?
How much of the development are you doing on Windows and how much on Linux?
Are you using an ORM to abstract the database? Which one?
Are you running a build engine on Linux? What about tests?
What other tools are you using?
How much additional work has it been to target Linux in addition to Windows?
What ugly or pleasant surprises have you encountered?
The company I work for targets Mono on Linux as our main deployment environment. Thus there is no "additional" work - we provide the whole stack, from hardware, through operating system (customized and trimmed) to applications. Using Open Source gives huge savings for us and our clients (and yes, we do contribute back to the OS Projects we rely on).
The important thing is to constantly test using your actual target (sorry, Mono on Windows doesn't count). Sure, developers use Visual Studio, but the continous integration (using CruiseControl.Net, you'll need Mono 2.4.2 to run it on Linux) is done both on Windows and Linux, testing all Mono versions we expect to work on (it got much more stable recently, but still, regressions do happen between releases). It's quite easy to run parallel Mono versions on one *nix system, you can even include an svn snapshot build if you prefer to catch upstream regressions early. If you don't roll out your own distribution, then remember that most Linux vendors ship Mono with custom patches - this has caused problems for us before. Also, many distributions have a lot of lag updating Mono, and this is a rapidly advancing project.
For database layer we use mostly "plain" ADO.NET - Oracle (with dotConnect for Oracle, they support Mono) and SQLite (Mono ships with a working connector). I have also used the official ADO.NET Driver for MySQL (Connector/NET) and it, too, works well. ORM mappings are more tricky, but NHibernate is usable (keep in mind that they do not support Mono officially).
As for the build engine and tests - NAnt and NUnit are well known and well tested. With most recent versions of Mono xbuild (clone of MSBuild) actually got usable, but prepare yourself for contributing quite a lot patches if you decide to use it for more complex scenarios.
Write tests. Lots of them. Be prepared to contribute patches and bugreports, and if you use commercial components - make sure the supplier officially supports Mono.
Nathan Bridgewater's blog has some nice articles showing, among other things:
running MVC3 with razor on mono
migrating ASP.NET MVC from Windows/SQL Server to Linux/MySQL
installing and running MonoDevelop
installing mono from source
http://iws.io/get-mvc3-razor-running-on-mono/
Take a look at the Mono project. Sounds like that is what you are looking for. If I remember correctly, they have ASP.NET MVC integrated into it now.
I have never worked with Mono, but from my understanding there are not many differences.