Cardboard Bazel BUILD files - google-cardboard

Now that Bazel is open source, can you include a BUILD file in the cardboard SDK repo? Correct me if I'm wrong but I believe internally all Google projects use Bazel (Blaze) so it shouldn't be too much of a hassle.
Thanks.

You might want to file this as a feature request in the Cardboard project. Internal BUILD files look a little different than the external ones, so even if there are BUILD files for it internally (which I'm not positive there are), it isn't exactly trivial.

Related

Universal .so file generation for all android studio projects

I know this question is there a lot on this platform, however, what I am looking for is the way for which I can generate .so files one time and can utilize them in all projects whenever I need them without any modification. is that possible?
If it is possible then what things need to be done?

Is it possible to distribute a NWJS app as a single exe-file?

I exported a game out of Construct 2 using their NWJS exporter. I need to distribute this game to a client who is not very technically adept to put it nicely. I think he would be able to run an exe-file by double-clicking it, but for example extracting a zip-file is probably too much to ask.
Is it possible to somehow distribute the result as a single executable file?
Here's what the folder that Construct made contains:
locales (folder)
d3dcompiler_47.dll
debug.log
dxwebsetup.exe
icudtl.dat
libEGL.dll
libEGLSv2.dll
natives_blob.bin
node.dll
nw.dll
nw.exe
nw_100_percent.pak
nw_200_percent.pak
nw_elf.dll
package.nw
resources.pak
Yes, use enigma virtual box or something similar. It can pack app into standalone app.exe with all files, libraries, etc.
Checkout How to package and distribute your apps on the NW.js official wiki
There are a few methods there covering not only windows.

When using someone else's application code do I need to run Cmake to get the project structure for my operating system.

I am getting into a position where I have to use other people code for projects, for example openTLD. I want to change some of the code to give it more functionality and use it in a diffrent way. What I have found is that many people have packaged their files in such a way that you are supposed to use
cmake
and then
make
and sometimes after that
make install
I don't want to install the software on my system. What I am looking to do is get these peoples code to a point where I can add to it in Eclipse or even just using Nano and then compile it.
At what point is the code in a workable/usable state. Can I use it after doing cmake or do I need to also call make? Is my thinking correct that it would be better to edit the code after calling cmake as opposed to before? I am not going to want my finished code to be cross platform supported, it will only be on Linux. Is it easer to learn cmake and edit the code befor running cmake as opposed to not learning cmake and using the code afterwards, if that is possible?
You question is a little open ended.
Looking at the opentld project, there is a binary and a library available for use. If you are interested in using the binary in your code, you need to download the executables(Linux executables are not posted). If you are planning to use the library, you have two options. Either you use the pre-built library or build it during your build process. You would include the header files in your custom application and link with the library.
If you add more details, probably others can pitch in with new answers or refine the older ones.

Cross platform installation conventions & best practices

I manage an open source project that we currently distribute as a zipped bundle of files. We provide a bundle for Windows and Mac -- we currently expect Linux users to compile it themselves.
This program comes with a bunch of auxiliary files that the user will need to access. These include example files and example/default scripts (like plugins) that the user will need to be able to easily find (preferably not searching through a maze of /usr/local/foo/examples/scripts).
The user will also have their own files (that they may want to store in random locations), but they will also have their own collection of scripts (that they probably want centralized so they are always available).
I would like to support installation in multi-user environments where the user does not have permissions to mess with the program installation. The program will include an API (shared library and header) and a Python wrapper for that too. It would be nice to make those available automatically.
We build the project with CMake - and currently use CPack to bundle the zip files. CPack has much more capability than we are currently using. This is not a mechanical question of how to build the package/installation files, but a convention question of where to put all the stuff?
We would like to have an Application on MacOS, an installer for Windows, and packages for Linux. Mac Apps package icons, fonts, images, etc. nicely, but they don't seem to support user-visible files very well.
I would love for there to be a cross-platform standard way of handling this situation, but I have trouble finding decent examples on individual platforms.
Is there anything better for us to do than just a zip of files?
Providing archive of those extra files is probably one of the best solutions. You may encourage users to download them on first start of program - let users decide where they want them themselves.

Script Create Package for Windows Store apps

I am maintaining a set of eleven Windows Store apps. I would like to automate the "Create Package" task, which I am currently doing through the wizard in Visual Studio, in order to produce test packages (signed with my test certificate).
Is there a way to script this task? I was thinking probably using MSBuild or PowerShell, my goal is to have a single script to run that would generate all my app packages and copy them all to a given target directory.
I found some documentation about using the wizard on MSDN, but nothing about scripting the task.
Any ideas?! Thanks.
MSBuild will create app packages for you, in the AppPackages folder. You can also do it manually using MakeAppx, but I've found it to be a bit more cumbersome.
Some things to note: There is a build target called Publish you should use (/t:Publish) when making the actual packages. You should look into the different command-line switches, such as DebugSymbols.
You'll likely want to use the 32-bit MSBuild, as I've had issues with the 64-bit and things like the Multilingual App Toolkit. Also in regards to the MApp Toolkit, make sure you do a full rebuild before building your app package. If an entry is not in a given language and is in another, the entry for the secondary language will be used, so you can end up with multiple languages all popping up on the same page.
Hope this helps and happy coding!

Resources