$ meteor --version
1.2.0.1
$ meteor add crosswalk
$ meteor build ~/build --server X
Results in an unaligned.apk that is 2.8MB. From what I understand, Chromium (which is much larger than that) should be included in the packaged app, so it must not be making it into the apk? How can I diagnose why that isn't happening? ~/build/android/project:
Yes, with Crosswalk included I would expect the APK to be at least 20MB.
Did you look in the project/build/outputs/apk directory? There should be APKs for multiple architectures there.
Related
VSCode, Java 11 JavaFX 18.0.2
I am trying to package my code up for distribution as a desktop app. In my case I want a fully self-contained app because of my target user's profile.
I have been through Jenkov add the Oracle docs here and here which suggest I need ant-javafx.jar. That jar file seems to have been dropped from the standard Java SDK some time around Java 7 and put into the regular JavaFX install lib folder.
It's not there in the build I have.
JavaFX seems to have gone to openjfx.io and nowhere in there can I see support for the ant packaging jar. In fact I see openjfx as a retrograde step as they are increasingly forcing everyone into paid plans (try going round and round the loop of downloading anything that doesn't require an LTS payment).
I have a suspicion that there is some silent assumption that everyone will use something from maven or gradle, and maybe the packaging tools are buried away in one of those build tools. For historical reasons I don't use either and it should be possible to do this packaging without one of them.
So where do I get the JavaFX Ant build tasks from without having to pay someone?
I have found that the following works as an alternative with Java 19 and OpenJFX 19. I use the maven-dependency-plugin to copy all the dependency jars (excluding JavaFX, which I use as modules from a "full" JDK [one that includes JavaFX)] into the target/lib directory.
#!/bin/bash
set -o errexit
set -o noclobber
set -o xtrace
# find dependency modules of required modules
DEP_MODS=$(jdeps -quiet --class-path "target/lib/*" --add-modules java.base,java.logging,java.sql,javafx.controls,javafx.fxml --multi-release base --ignore-missing-deps --print-module-deps target/myapp-4.0-beta.jar)
# create a modular runtime image
jlink --compress=1 --no-header-files --no-man-pages --add-modules "java.logging,java.sql,javafx.controls,javafx.fxml,$DEP_MODS" --output target/myapp-4.0-beta
# Example of running it out of the runtime image
# TEST target/myapp-4.0-beta/bin/java -cp "../../myapp-4.0-beta.jar:../../lib/*" org.myapp.App
# symlink to the artifact jar from the lib directory
$(cd target/lib && ln -s ../myapp-4.0-beta.jar)
# use the lib directory and modular runtime image as input to jpackage
jpackage --input target/lib --runtime-image target/myapp-4.0-beta --main-jar myapp-4.0-beta.jar --main-class org.myapp.App --type app-image --app-version 4.0 --name app --dest target/dist/bundle --mac-entitlements src/dist/mac/entitlements.plist
I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!
After upgrading Meteor to 1.3.x version NPM really came to play. But as always there is back side of the coin: build size.
On meteor 1.2.x build size is ~50MB, ~7k files
On meteor 1.3.x build size is ~190MB, ~27k files.
Twenty seven thousand files. That's quite a number. Not to mention path size exceeding 256 (a trouble for windows users).
I've dig into what meteor included into the build and it seems that all the npm_modules is here with all the stuff that is need to build some modules and their dependencies.
The question is: how to build meteor app without unnessesary npm files, leaving only the ones that are actually used by app at runtime?
Update:
On meteor 1.4.1_3 if you create a simple project meteor create dummy-project and go through all the common stuff like npm meteor install and meteor npm prune --production and them make a bundle out of it with meteor build c:\dummy --directory you will get a folder with the same 7k files and almost 2k folders (by the way it will not run node main.js out of the box as you might expect). If you tinker through folders you can find babel compiler inside that takes ~3.5k files.
Why do I need babel compiler inside compiled app?
To gain an introspective of your packages,
npm list --depth 0
to see the current packages in your project with only one level.
Inspect that list, and decide if you don't need a package and uninstall it.
You can also use other flags such as
npm list --depth 1 #the number represents the max depth
npm list --long true #for more information about the packages
npm list --global true #to check your global packages.
npm help-search <searchTerm>
Hope that helps you gain more insight in your packages. help-search Link
You may see that multiple packages depends on the same packages, and then it's up to you to decided what your application needs to run successfully.
Edit 1
You can exclude the packages inside your devDependencies, so that when you're publishing/deploying your code you have a cleaner package.
You do this by using npm prune --production - that removes all your devDependencies, and will require your users to do a npm install for your package to work. For info here
I have followed the instructions given in the readmes of both bootstrap3-less and meteor-bootstrap-3 meteorite packages, but it seems there are steps missing.
Could someone explain, to an inexperienced developer, exactly (step-by-step) how to 'upgrade' from the Meteor package bootstrap to Bootstrap 3 (preferably with LESS but not essential)?
Some specific queries:
Should I uninstall the standard bootstrap package first?
Where does one reference the new .less or css files (or is that done as part of the mrt package)?
Any other best practises
Thanks.
It is almost just like you actually said. Assuming your are on linux/mac, make sure you are at project root directory and then
$ mrt remove bootstrap
$ mrt add less
$ mrt add bootstrap3-less
$ mkdir -p client/styles
$ touch client/styles/my-styles.less
$ sed -i '$ a\#import "/packages/bootstrap3-less/bootstrap.import.less";' client/styles/my-styles.less
$ cd public && ln -s ../packages/bootstrap3-less/lib/fonts ./
That's it. For further customization and advanced usage, take a look at the official readme at https://github.com/simison/bootstrap3-less
Also, search atmosphere for keyword bootstrap and you'll find lots of packages that you can include in your project.
Also, packages get updated from time to time.
Therefore, once in while, make sure you run in your project root directory:
$ mrt update
Or if you are cloning your project from git to a new workspace, you need to install third party packages first:
$ mrt install
I am writing c++ program using poco c++ library and execute in PC environment successfully. But how to cross compile into ARM-Linux .
I am following from the poco GMakeBuildNotes, but I do not know where I made mistakes. Can anybody help me how to cross compile step by step. Here are the steps I am currently following:
./configure --config=ARM-Linux --no-samples --no-tests
make
cross compile in QT framework
Any suggestions to improve these steps, please?
This post is old and you didn't really stated what's the problem, but still I'll share. I'm getting started with poco for our embedded systems and this is how I compiled it for ARM linux:
If you download and unpack the poco package, you'll find a directory: build/config
Here you can find various preset configs for poco builds. I made a copy of 'ARM-linux' and edited it to suit my needs (these are only the changes):
LINKMODE ?= STATIC # since we are statically linking poco...
...
TOOL = arm-none-linux-gnueabi # this is the compiler we use
The rest was okay for me!
Then I compile poco like this:
$ ./configure --config=MY_OWN_CONFIG --prefix=/absolute/path/to/target/dir --no-samples --no-tests
$ make (compiles without a problem for me)
$ make install
after 'make install' (if everything is fine) the compiled libs will be in the directory specified by the '--prefix' option, and they are ready to be linked to your ARM applications.
I hope it helps!