How does version control and collaboration work with Amber?
When I created a new package I saw that three files were created:
js/MyPackage.deploy.js
js/MyPackage.js
st/MyPackage.st
Do I need to put all of them under version control?
Can I merge changes into only the .st file and have the Amber server pick them up?
First a short explanation of the three files:
st/MyPackage.st: the Smalltalk source also known as fileout
js/MyPackage.js: the equivalent to the Smalltalk source compiled to JS (including metadata such as Smalltalk sourcecode)
js/MyPackage.deploy.js: equals the other .js file but does not contain metadata not needed in deployment
To run an Amber application one of the .js files is needed.
Which one depends on the deploy mode but for development the one without .deploy in the name is used.
The .js files in turn can be generated from the .st files using the Amber commandline compiler (e.g. through Grunt.js) or by doing a file-in in the IDE and commiting the relevant package.
In general, we keep all three files under version control but for now the most crucial ones are the .st files since those are usually easier to merge than generated JS code.
However, keeping and merging only the .st files is not sufficient since those are not loadable by Amber.
Nico for example uses a local git hook to recompile the .st files upon pulling the latest changes.
See this message from the Amber mailinglist.
Related
Once again a mystery from Project A and Project B. I can compile Project A without problems. Both projects have their source .PAS files in the same directory but they are separate projects.
I use a partition called Drive-O and a subdirectory within Drive-O to host the projects. However, when I load project B most, but not all of the .PAS files are shown with little red Xs. So it appears they were not found by the compiler in Project B, but no problems with project A.
Curiously I examined the [closed files] in the .DSK files and found that for Project A all files showed uniform paths "O:\SubDirectory\xxx.pas" but in B.dsk there was a mixture of valid paths and an old location for the project in Users\Martel\Subdirectory\xxx.pas.
So this appears to be problem. Is there way to correct this discrepancy? Where does the .DSK file get its data, and what is its role in loading a project? Might I delete the file and have it rebuilt?
All explained above.
I have a fairly new project on github that produces a shared library. Going forward, I would like to use semantic versioning (as described at semver.org) for the shared library major/minor/patch numbers in the file name. The project uses CMake. The CMakeLists.txt file refers to CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH, and sets these to default values if they are not passed in on the command line.
My plan is to branch on ABI changes and API additions, according to semantic versioning principles.
I know github has support for creating and naming release packages containing the project source based on git tags. But I do not see a way to propagate the major, minor and patch numbers to the shared library name when the github user builds a release on their machine.
For example, if I have a branch called, myproj_1_2, and a release tag called myproj_rel_1_2_9, is there a way to have the shared library built by a user be name libmyproj.so.1.2.9?
Is this just a matter of documenting that a user should pass the build name information on the cmake command line, and the have the CMakeLists.txt file parse this and set CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH accordingly, or is there a more elegant way to do this?
Your statement about how CPACK_PACKAGE_VERSION_XXX is set is incorrect. The CPack variables in question are set by the project command if the project command specifies versioning. So when you create the 1.2.9 branch you would set 1.2.9 as the version number in the project command.
From CPack Help
CPACK_PACKAGE_VERSION_MAJOR
Package major version. This variable will always be set, but its default value depends on whether or not version details were given to
the project() command in the top level CMakeLists.txt file. If version
details were given, the default value will be
CMAKE_PROJECT_VERSION_MAJOR. If no version details were given, a
default version of 0.1.1 will be assumed, leading to
CPACK_PACKAGE_VERSION_MAJOR having a default value of 0.
Project command
> project(<PROJECT-NAME>
> [VERSION <major>[.<minor>[.<patch>[.<tweak>]]]]
> [DESCRIPTION <project-description-string>]
> [HOMEPAGE_URL <url-string>]
> [LANGUAGES <language-name>...])
If you don't want to set the VERSION via the project command then there are multiple other ways of setting the relevant variables.
Examples are located:
https://cmake.org/cmake-tutorial/
Also look at how CMake handles versions:
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/CMakeVersionSource.cmake
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmVersionConfig.h.in
Another example of how to get git meta data for setting version related information:
https://github.com/pmirshad/cmake-with-git-metadata/blob/master/CMakeLists.txt
I am attempting to convert parts of an Android app to iOS using Doppl, and I am getting a strange result: Doppl keeps trying to pull in android.arch.lifecycle:reactivestreams, even though I don't want it to.
Specifically, in app/build/j2objcSrcGenMain/android/arch/lifecycle/, there is a reactivestrams/ subdirectory with R.h and R.m files in it. This seems to make Xcode cranky and may explain why I had some oddities with pod install.
My app/build.gradle has compile "android.arch.lifecycle:reactivestreams:$archVer", because my activity is using LiveDataReactiveStreams.fromPublisher(). However:
The activity is not in the translatePattern (and since its code is not showing up in app/build/j2objcSrcGenMain/, I have to assume that the translatePattern is fine)
I do not have a doppl statement related to reactivestreams, because there does not appear to be a Doppl conversion of this library (nor should it be needed here)
AFAIK, nowhere else in this app am I referring to LiveDataReactiveStreams, which AFAIK is the one-and-only public class from the reactivestreams library
So, the questions:
What determines whether Doppl creates R.h and R.m files for some dependency? It's not the existence of a doppl statement, as I have doppl statements for a lot of other dependencies (RxJava, RxAndroid, Retrofit) and those do not get R.h and R.m files. It's not whether the dependency is referenced from generated code, as my repository definitely uses RxJava and Retrofit, yet there are no R files for those.
How can I figure out why Doppl generates R.h and R.m for reactivestreams?
Once I get this cleared up... do I re-run pod install, or is there some other pod command to refresh an existing pod with a new implementation?
Look into 'app/build/generated/source/r/debug' and confirm there's an R.java being created for the architecture component. It'll be under 'android/arch/lifecycle/reactivestrams'.
I think there are 2 problems here.
Problem 1
Somehow Doppl/J2objc is of the opinion that this file should be transpiled. It could be either that 'translatePattern' matches with it, or that something in the shared code is referencing it. If you can't figure out which, please post a comment and I'll try to help (or post in slack group).
Problem 2
Regardless of why that 'R.java' is being sucked into the translate step, because of how stock J2objc is configured, the code is being generated with package folders instead of creating One Big Name. That generated file should be called 'AndroidArchLifecycleReactivestramsR.h' (and AndroidArchLifecycleReactivestramsR.m). Xcode really doesn't like package folders. That's why there's a slightly custom J2ojbc being used with Doppl, so we can have files with big names instead of folders.
In cases where you intentionally use package names that match with what J2objc considers to be "system" classes, you need to provide a header mapping file to force long names. The 'androidbase' doppl library needs to add a lot of files that are in the 'android' package, which J2objc considers "system". We override those names in the mapping file.
build.gradle
https://github.com/doppllib/core-doppl/blob/master/androidbase/build.gradle#L19
mapping file
https://github.com/doppllib/core-doppl/blob/master/androidbase/src/main/java/androidbase.mappings
I screwed up.
In my dopplConfig, I have:
translatePattern {
include '**/api/**'
include '**/arch/**'
include '**/RepositoryTest.java'
}
In this case, **/arch/** not only matches my arch package, but also the arch package from the Architecture Components.
Ordinarily, this would not matter, because the Architecture Components source code is not in my project. But, R.java gets generated, due to resources, and the translatePattern includes generated source code in addition to lovingly hand-crafted source code. So, that's where my extraneous Objective-C was coming from.
Many thanks to Kevin Galligan for his assistance with this, out on the #newbiehelp Doppl Slack channel!
I have a large project which contains many libraries that the main binary depends on. I would like to know what the proper way to handle this in launchpad so I can build the libraries, then the main binary and offer each debian pacakge on a ppa.
You can see the project in question at lp:snapcpp (https://code.launchpad.net/snapcpp/). In snacpp, we have "snapwebsites", a C++ CMS system which attaches to a Cassandra database via our library "libQtCassandra." "snapwebsites" depends on libQtCassandra, as it does libltd, and others. Each of these libraries need to be separate debian packages themselves. Each project has its own "debian" folder but there is no root debian folder at this time.
How can I get this to work on launchpad, which requires a root debian folder? Do I need to construct a debian project at the root that lists each dependency? If not, do I need to break up each project into its own branch using bzr? If I do the latter, how do I call out those depencency debs for the build (in other words, how do I tell the recipe for snapwebsites that it needs to have libQtCassandra and its dependency packages installed)?
Thanks!
The solution that I discovered on my own was to utilize the recipe command "nest-part," which allows you to take a single folder out of a bzr branch and map it into your project. It cannot, however, map to the root of your branch.
What I did was to create a branch with only packaging information in it, and a CMakeLists.txt file containing "add_subdirectory(src)". Then I map from the main code branch (lp:snapcpp), but only the project in question. For example, here is the recipe for the "controlled_vars" project in snapcpp:
# bzr-builder format 0.3 deb-version {debupstream}+{revno}
lp:~snapcpp/snapcpp/controlled_vars
nest-part src lp:snapcpp controlled_vars src
There does need to be a branch with packaging information with each sub-project, but this is a one-time set up issue.
Working on the new android side of extensions with the changes. I have my separate extension as its own dependency.
In my code I require references to the Extension.Java class as well as the HaxeObject.
These are located in extensions-api, which is it's own separate dependency.
I've tried including these files in my own dependency, this causes top-level exceptions because a number of the Java files were included twice. I've also tried not including the extensions-api, this works to some extent, however If in the future I decide to use more extensions this won't work (less than ideal).
I need to find a way to reference these files from one dependency to another. so from: MyExtension.src.org.haxe.nme.MyExtension and extension-api.src.org.haxe.nme.Extension
So I guess the point I'm stuck at is how I make these two dependencies see each other whilst compiling so that when they merge to make the .dex file they don't cause top-level exceptions.
I could potentially hack it by placing my extension into the extension-api folder. Something like:
<dependency name="extension-api" path="dependencies/MyExtension" if="android"/>
The issue with this being that the androidManifest merging wouldn't work.
I found the answer here:
the gist is in the project.properties file you want to add the line:
android.library.reference.1=../extensions-api
http://www.openfl.org/community/general-discussion/native-extensions/