i have a separate build-flow that can produce .out files for the MT3620/M4 core using the same gcc-arm compiler.... for reasons beyond the scope of this question, it's not practical for me to migrate this build-flow into cmake....
once i generate the .out file, my thinking was to simply envelop it within a project structure identical to the samples -- with an conforming app_manifest.json file.... from here, i could effectively run just the final step of the cmake build -- which generates the image package....
before i go down this path, is there anything obvious i'm missing here????
As of today you will need to decide to install Azure Sphere SDK Preview for Visual Studio or Azure Sphere SDK Preview for Windows (You cannot install both SDKs on the same PC.)
To develop applications, however, you need to set up your development environment and possibly install additional tools. The Azure Sphere SDK for Windows supports development with the CLI only. If you've installed this version of the SDK, you'll need to install CMake and Ninja on your PC.
If you plan to develop real-time capable applications (RTApps), you might need to install a compiler for the embedded processor and set up hardware to display output from the app.
Both Quickstarts "Build an RTapp on cmd" and "Build an RTApp with Visual Studio" require that you use CMake at some stage and those are the supported methods.
Update: New documentation improvements will be done soon to address the option of using a different build system to cmake and "yes" it should work as you suggest.
Related
I'm attempting to build TensorFlow's C++ library for Windows XP. While I've been able to build and use it on Windows 10, 32-bit XP isn't working. The background: I'm working on a COM module that calls fuctions from tensorflow.dll. My build environment:
Visual Studio 2017 15.7
CMake 3.11.1
TensorFlow 1.8
Windows 10
The sequence I use to build tensorflow.dll is:
Open "x64_x86 Cross Tools Command Prompt for VS 2017"
Try to force the use of functions availablbe in Win XP: set CXXFLAGS=/D_WINVER=0x0501 /D_WIN32_WINNT=0x0501
Add Git to path: set PATH=%PATH%;C:\Program Files (x86)\Git\bin
Fix CMake file for converting *.proto files to *.pb.h files as described here.
Configure CMake: cmake .. -A Win32 -T v141_xp,host=x64 -DCMAKE_SYSTEM_VERSION=7.0 -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=C:\Users\williams\AppData\Local\Continuum\Anaconda3\envs\tensorflow\python.exe -Dtensorflow_BUILD_SHARED_LIB=ON -Dtensorflow_BUILD_PYTHON_BINDINGS=OFF -Dtensorflow_WIN_CPU_SIMD_OPTIONS="/arch:IA32"
Build: cmake --build . --target tensorflow --config Release -- /fileLogger /m:1 /p:CL_MPCount=1
The last step also involves some manual labour as the build process doesn't copy .lib files from the 3rd part dependencies to where they are needed. For whatever reason, a bunch of INSTALL projects never get run so I had to do that manually each time the build would fail while looking for a missing lib file. Once that was done, the build completed successfully.
Next I copy my COM module (a DLL) and the TensorFlow DLL over to a Windows XP virtual machine for testing and try to register the COM module, but get an error LoadLibrary("MyDLL.dll") - The specified procedure could not be found. I don't know what procedure it is looking for, so the best I can offer is that Dependency Walker highlights WS2_32.DLL and tells me it can't find inet_ntop and inet_pton.
Any suggestions on how to build TensorFlow so that it doesn't use these two functions?
P.S. suggestions of "Stop using XP, its old and no longer supported" don't help here. Upgrading to Windows 10 is an absolute last resort because of the disruption it would cause at the facility where this software will be tested.
Edit 1:
These two functions inet_pton and inet_ntop were only used in one file that forms part of Google Cloud Storage support in TensorFlow. The build process generated a tensorflow_static.lib in addition to tensorflow.dll. Linking against the static version and adding a few dependencies that aren't included in tensorflow_static.lib got rid of the code using inet_* functions.
My COM module still isn't working on Windows XP though because the file tensorflow\core\platform\windows\env.cc uses functions like CloseThreadpoolWork, submit SubmitThreadpoolWork, etc. that were only introduced in Windows Vista. It looks like I'll have to replace them with something else, as I don't see an alternative implementation in TensorFlow.
Additionally, I found that tensorflow\contrib\cmake\CMakeLists.txt forces _WIN32_WINNT=0x0A00 and that CXXFLAGS is the wrong environment variable to use. Changing it to CMAKE_CXX_FLAGS at least gets my macro definitions included, FWIW.
It is almost impossible to port tensorflow to windows xp, because:
TF's platform depedent code requires some Windows APIs later than winxp such as Thread Pool API. This would possibly bypassed by using third party thread pool libs.
The nsync, protobuf and eigen, which are core parts of TF, use C++11 thread_local, which makes them unable to run-time load as dll, see https://learn.microsoft.com/en-us/cpp/parallel/thread-local-storage-tls?view=vs-2017 for details. This later feature can theoretically be replaced by old windows TLS API, which requires many modifications on TF's core framework.
Anyway, if you really need the xp support, good luck with that.
In the end I gave up on this as simply being impossible. Even replacing the thread pool functions with something from Boost didn't help. If someone else manages to get this working, I'll gladly accept that as the answer, but so far this looks impossible.
I have installed Yocto, and successfully ran host-prepare.sh script. I want to know that, to develop makefile based applications, what to do next, should install toolchain or ADT or kernel & filesystem images? Is there any documentation which has step by step process?
In many cases, one do not need to install Yocto at all, what is needed is just appropriate toolchain along with filesystem image to develop and test simple program with qemu (runqemu - which is emulator - a part of toolchain). These toolchains and filesystem images are available to download and ready to use. Refer 'Using Pre-Built Binaries and QEMU' section in this documentation.
I'm prepping an application for submission to the Windows Store that utilises the Bing Maps API - as such, the app has to be compiled to target specific architectures. Whilst there is a guide to submission, it's not clear how to submit both Arm and x86 configurations of the same app. Is it even possible, or will there have to be in the store twice?
When you select the option to create your app package from the Visual Studio Store menu, you get a choice to select the package architecture. There are 4 options: Neutral, x86, x64, ARM.
If you select Neutral, then it builds a single package for "Any CPU" that you can upload to the Store. If you select x86, x64 and ARM, it will build a package for each of these configurations, and you will have to upload the corresponding packages for the architectures you wish to support.
Additionally, if you're building to submit to the Store, make sure to always select Release for each of the selected architectures.
There are cases where some references don't support building using a Neutral architecture. The Microsoft Visual C++ Runtime Package is an example.
Taken from here:
The process of engineering for ARM was different for each language (JavaScript, C++, and C#/VB), based on existing implementation details
of the various runtimes and compilers.
JavaScript uses a JIT compiler, so platform targeting is taken care of at runtime. Therefore Metro style apps using JavaScript are
platform neutral, and you can write once to run on x86/x64/ARM.
C# and Visual Basic are also abstracted from hardware differences. They compile to MSIL, which is platform neutral. Therefore, Metro
style apps using C# or Visual Basic can be compiled once to run on
x86/x64/ARM.
C++ is close to the metal, and compiled to the machine language for
the platform that you’re targeting. This offers developers full
control, but also requires that they specify the hardware where the
app will be supported.
The essence of it is that pure .net or pure html/js will run on any architecture without problems. If you want C++ then you will need to compile your app once for each supported architecture. My understanding is that you can create an app package which contains installers for multiple architectures in this case.
The post here has some good details on packaging your app for multiple architectures. Here are a few highlights:
7.In the Select the packages to create and the solution configuration mappings section, select the check box for each build configuration
for which you want to create a package.
The build configurations grid lists the possible platform
architectures of the package (that is, Neutral, ARM, x64, and x86). In
each row, a combo box displays the combination of the current Solution
Configuration and Architecture choices that are relevant for that
row’s architecture. The check box for the default platform is set to
the current, active project platform. The combo box for the Neutral
row show the Solution Configuration combinations that contain AnyCPU
as the project’s platform. If no Solution Configuration combination is
relevant, the entire row for that platform is unavailable for
selection. One package is produced for each configuration that you
specify.
8.For each build configuration that you specified, choose the Solution Configuration that you want to build.
When you package an app for the Store, you can specify Release or any
custom solution configuration that you’ve created.
A package will be created for each build configuration that you
specified.
From here we get this:
7.Click Packages to upload your app's packages.
And finally from the previous link:
Signing and publishing
After your app passes the certification testing, its packages are
digitally signed to protect them against tampering after they have
been released. When this phase begins, you cannot cancel your
submission.
Note It might take some time for your app's listing to appear in
search results. This is normal. Also, you can't change a release date
after you submit the app to the Windows Store, but you can cancel the
release, update the release date, and re-submit.
Overview: During the build process you specify all architectures you want your app to work for and it creates a package for each. During the submission process you select all the packages you built for that app. When submitting you app this way only one version will show up in the store.
If you build just a HTML5/javascript Windows Store app, it work on all version (ARM, x86 and x84)
If you create something web with bing api. No worry about what platform doesn't work.
Answer is here: http://developer.android.com/google/play/publishing/multiple-apks.html
TLDR:
Go to your Google Play app developer console
Choose your app
Select APK on the left
Turn on Advanced Mode
Upload your ARM apk
Upload your x86 apk
Google will figure out the rest
I can build the google breakpad client, the stackwalker can convert the dump to human readable txt file. But there is no gyp file to make vs2008 solution. Does anyone know how to build the stackwalker on windows. Thanks
The stackwalker tool doesn't build using Visual C++ currently. You can build it with Cygwin if you install that whole toolchain. If you'd find it useful there's a prebuilt Cygwin minidump_stackwalk binary that Mozilla uses on our build machines.
Along with the matching Cygwin support DLLs:
cygwin1.dll,
cygstdc++-6.dll,
cyggcc_s-1.dll.
It's slightly out-of-date but should work fine.
Also note that you should be able to load Windows minidump files directly into a debugger on Windows, like Visual C++ or WinDBG.
As good developers we keep our code as standard compliant as possible to help in porting between platforms. But what tools are available that help us build the code in a uniform way across multiple platforms.
*nix family has make but Windows needs nmake.
I have read about SCons but never used it in anger. What is your favorite build tool, why do you find it effective and are there any limitations (i.e. platforms with bad support etc).
Cross platform IDEs as well.
cmake for c/c++ environments is good. http://www.cmake.org/
I personally use ant, rake, and maven2. I have used ant the most and find it great for several reasons:
Because it is java it works on lots of platforms (without changing any scripts)
The build files are written in XML and fairly easy to write
There are lots of 3rd party extensions available for it and it is easy to write plugins for
we do extreme cross development, and our code runs on linux, windows ce, windows 2K, nucleus and uCOS-II.
since each environment uses different 'make' methodology (out nucleus customer, for example, require us to compile via code-warrior GUI).
i used ANT combined with perl for about 2 years, but this lead the build script to total non-maintainability.
now we moved to use python, which increase the maintainability of the scripts.
bottom line, i did not find a ready-made tool, and had to build my own. maybe, when i have some time (2017 ?) i will pack my scripts and distribute them ....
If you're in the Java world, there are quite a few tools which are cross-platform. Apache Ant and Maven are both build tools which will run on any platform which has Java available for it.
Cruise Control (continuous integration tool) also works on Windows and Linux (it's written in Java as well).
I haven't had any real issues with the core tools, the only problems I've sometimes had have come from things external to the build process, i.e. publishing artifacts - this will vary between systems so I've found there's no single way of setting it up.
For C/C++ development, I've found that bakefile works well. The fairly large wxWidgets project, a cross-platform cross-platform utility and UI library, uses it for their build file generation.
Bakefile is cross-platform, cross-compiler native makefiles generator. It takes compiler-independent description of build tasks as input and generates native makefile (autoconf's Makefile.in, Visual C++ project, bcc makefile etc.).
Bakefile's task is to generate native makefiles, so that people can keep using their favorite tools. There are other cross-platform make solutions, but they either aren't native and require the user to use unfamiliar tools (Boost.Build) or they are too limited (qmake).
You can use gmake on Windows as well with cygwin/minGW or build your windows stuff on Linux.
http://cdtdoug.blogspot.com/2009/05/mingw-cross-for-linux.html
There are tools like Opus Make or MKS Toolkit that offers multiplatform and support. If you have an existing codebase of make script, could be easier migrate to one of there. I suspect you may hunt for similar tools in advertising of DDJ magazine.
We've been running a Java environment for Linux, Windows and the Mac for the last 18 months.
Maven 2 drives our builds, it's pretty easy to get things consistent here. Where M2 plugins don't dare to tread, we use small Ant scripts.
IDE-wise we're using Eclipse & IDEA - both, of course, multi-platform.
Testing - JUnit, Fitnesse, Fest - all nicely multi-platform.
Release scripts are written in Ruby. There's a bit more trouble with Windows here, but a function to convert paths as necessary generally does the trick.
TeamCity does CI. We've actually migrated this from Windows to Linux and encountered no errors at all, very nice package.
We did use GWT for a while and this did cause us large amounts of pain. Be careful if you swing that way.