compile mixed Kotlin and Java code from the command line - kotlin

I'd like to start adding some Kotlin to my Java project. To do that I need to be able to compile both Java and Kotlin files from the command line, which is fine apart from when files of different types depend on each other e.g. A.java depends on B.kt which in turn depends on C.java.
Is there any way to do this without using Gradle, Maven etc?
Edited to clarify thanks #Nikita for pointing out it is not clear that I want both java and Kotlin files in the same source tree

To achieve this, you will need to run two steps.
Run kotlinc targeting *.kt files. Add all required java sources on classpath. Note the destination location.
Run javac targeting *.java files. Add *.class files created by step 1 to classpath.
Result is a combination of *.class files from both steps.
Here is a documetation on Kotlin compiler

Remember to compile Kotlin first, then compile Java with kotlin-build-classpath from first step.
simple like this:
1. kotlinc ./src/* -d ./buildTmp
2. javac ./src/**.java -d ./buildTmp -classpath ./buildTmp

Related

add_custom_command() not compiling my project glib resources [duplicate]

I'm trying to use add_custom_command to generate a file during the build. The command never seemed to be run, so I made this test file.
cmake_minimum_required( VERSION 2.6 )
add_custom_command(
OUTPUT hello.txt
COMMAND touch hello.txt
DEPENDS hello.txt
)
I tried running:
cmake .
make
And hello.txt was not generated. What have I done wrong?
The add_custom_target(run ALL ... solution will work for simple cases when you only have one target you're building, but breaks down when you have multiple top level targets, e.g. app and tests.
I ran into this same problem when I was trying to package up some test data files into an object file so my unit tests wouldn't depend on anything external. I solved it using add_custom_command and some additional dependency magic with set_property.
add_custom_command(
OUTPUT testData.cpp
COMMAND reswrap
ARGS testData.src > testData.cpp
DEPENDS testData.src
)
set_property(SOURCE unit-tests.cpp APPEND PROPERTY OBJECT_DEPENDS testData.cpp)
add_executable(app main.cpp)
add_executable(tests unit-tests.cpp)
So now testData.cpp will generated before unit-tests.cpp is compiled, and any time testData.src changes. If the command you're calling is really slow you get the added bonus that when you build just the app target you won't have to wait around for that command (which only the tests executable needs) to finish.
It's not shown above, but careful application of ${PROJECT_BINARY_DIR}, ${PROJECT_SOURCE_DIR} and include_directories() will keep your source tree clean of generated files.
Add the following:
add_custom_target(run ALL
DEPENDS hello.txt)
If you're familiar with makefiles, this means:
all: run
run: hello.txt
The problem with two existing answers is that they either make the dependency global (add_custom_target(name ALL ...)), or they assign it to a specific, single file (set_property(...)) which gets obnoxious if you have many files that need it as a dependency. Instead what we want is a target that we can make a dependency of another target.
The way to do this is to use add_custom_command to define the rule, and then add_custom_target to define a new target based on that rule. Then you can add that target as a dependency of another target via add_dependencies.
# this defines the build rule for some_file
add_custom_command(
OUTPUT some_file
COMMAND ...
)
# create a target that includes some_file, this gives us a name that we can use later
add_custom_target(
some_target
DEPENDS some_file
)
# then let's suppose we're creating a library
add_library(some_library some_other_file.c)
# we can add the target as a dependency, and it will affect only this library
add_dependencies(some_library some_target)
The advantages of this approach:
some_target is not a dependency for ALL, which means you only build it when it's required by a specific target. (Whereas add_custom_target(name ALL ...) would build it unconditionally for all targets.)
Because some_target is a dependency for the library as a whole, it will get built before all of the files in that library. That means that if there are many files in the library, we don't have to do set_property on every single one of them.
If we add DEPENDS to add_custom_command then it will only get rebuilt when its inputs change. (Compare this to the approach that uses add_custom_target(name ALL ...) where the command gets run on every build regardless of whether it needs to or not.)
For more information on why things work this way, see this blog post: https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
This question is pretty old, but even if I follow the suggested recommendations, it does not work for me (at least not every time).
I am using Android Studio and I need to call cMake to build C++ library. It works fine until I add the code to run my custom script (in fact, at the moment I try to run 'touch', as in the example above).
First of,
add_custom_command
does not work at all.
I tried
execute_process (
COMMAND touch hello.txt
)
it works, but not every time!
I tried to clean the project, remove the created file(s) manually, same thing.
Tried cMake versions:
3.10.2
3.18.1
3.22.1
when they work, they produce different results, depending on cMake version, one file or several. This is not that important as long as they work, but that's the issue.
Can somebody shed light on this mystery?

Encapsulating a JNI library inside a jar file

I am trying to develop a plugin for Fiji/ImageJ that relies on a native library (JNI).
The JNI library itself depends on libtiff and fftw. On OSX and Linux, I use the class NativeUtils and everything works fine.
On windows, I included binary versions of libtiff and fftw in the CMake package and managed to link the JNI library against those (either statically of dynamically). However, the resulting JNI module does not include libtiff or fftw and I obtain an error when I try to load the JNI library with NativeUtils.loadLibraryFromJar. This is also the case when I include the dependent .dll in the .jar since they are not extracted by NativeUtils.
Here are the relevant lines in CMakeLists.txt:
add_library(fftw STATIC IMPORTED GLOBAL)
set_target_properties(fftw PROPERTIES IMPORTED_LOCATION "${libdir}/libfftw3f-3.lib"
INTERFACE_INCLUDE_DIRECTORIES "${incdir}")
SWIG_ADD_LIBRARY(javainterf
TYPE MODULE
LANGUAGE java
SOURCES javainterf.i javainterf.c src1.c)
SWIG_LINK_LIBRARIES(javainterf libcode1 fftw)
add_jar(Foo
SOURCES ${CMAKE_CURRENT_BINARY_DIR}/java/foo1.java
INCLUDE_JARS java/resources/ij-1.51p.jar
VERSION ${JAR_VERSION})
add_dependencies(Foo javainterf)
add_custom_command(TARGET Foo POST_BUILD
COMMAND "${Java_JAR_EXECUTABLE}" -uf Foo-${JAR_VERSION}.jar
-C ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR} ${JNI_LIB_NAME})
How would you make sure that all the dependencies are properly included in the jar and loaded?
You can't load library from inside JAR without extracting it in a first place.
Take a look here at full sample where native code is embedded inside JAR and extracted when needed.
https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo031
Update
Well, in that case, when you need to pack more libs and you want to properly resolve locations, you need to play with runtime env a little bit.
Take a look here:
https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo035
git clone https://github.com/mkowsiak/jnicookbook
cd jnicookbook/recipes/recipeNo035
make
make test
Have fun with JNI!

How can I get the Frege compiler to see Android API classes when using Gradle?

I am attempting to write an Android app using the Frege language. Unfortunately, I'm not aware of any examples of how to do this.
So, I'm using Gradle as my build system, with the Android Gradle plugin. Then to get the Frege code to be compiled, I'm using a javaexec to call the frege compiler before the Java files get compiled, as suggested in this post.
I was successful in building an Android application with Frege code that gets called by Java code, as shown here.
However, the Frege code can only call standard Java APIs. It can't call any of the Android APIs.
I'd like to be able to call Android APIs from Frege. There is a nice repo here that has Frege wrappers for the Android APIs. Unfortunately, it has no build system or instructions.
I believe I've successfully set up my build.gradle to build the FregeAndroid wrappers along with my project's code. The Frege compiler is indeed attempting to build them.
However, the FregeAndroid code fails to compile, because it can't see the Android API classes. I assume I need to somehow find where the Android API classes are, and then add that to the Frege compiler's classpath, so it can see those classes. Unfortunately, this is where I'm stuck. I'm a newbie at Gradle, and can't figure out how to do this.
Here is my project which I have so far, which fails to build, in the following way:
:compileDebugJavaWithJavac
Frege compiler args: "-inline -d src/frege -make -fp /Users/ppelleti/Library/Android/sdk/platforms/android-21/android.jar -sp /Users/ppelleti/programming/android/frege-on-android/FregeAndroid/src /Users/ppelleti/programming/android/frege-on-android/FregeAndroid/src/frege/android/animation/TimeInterpolator.fr"
calling: javac -cp /Users/ppelleti/.gradle/caches/modules-2/files-2.1/org.frege-lang/frege/3.23.401-g7c45277/716990197271fdc15917b4f8d023d63009ba6e39/frege-3.23.401-g7c45277.jar:/Users/ppelleti/Library/Android/sdk/extras/android/m2repository/com/android/support/multidex/1.0.0/multidex-1.0.0.aar:src/frege:/Users/ppelleti/Library/Android/sdk/platforms/android-21/android.jar -d src/frege -sourcepath /Users/ppelleti/programming/android/frege-on-android/FregeAndroid/src -encoding UTF-8 src/frege/frege/android/animation/TimeInterpolator.java
runtime 4.282 wallclock seconds.
Frege compiler args: "-inline -d src/frege -make -fp /Users/ppelleti/Library/Android/sdk/platforms/android-21/android.jar -sp /Users/ppelleti/programming/android/frege-on-android/FregeAndroid/src /Users/ppelleti/programming/android/frege-on-android/FregeAndroid/src/frege/android/app/Activity.fr"
Android.app.TaskStackBuilder: build failed because module is not on class path
Android.app.Fragment: build failed because module is not on class path
Android.app.LoaderManager: build failed because module is not on class path
[... omitted a bunch of similar lines ...]
Any ideas would be much appreciated!
It turns out that there were several problems, including problems with both the source path and the classpath. I've updated my repository to fix these problems.
However, ultimately the build fails because there are files missing from the FregeAndroid repo. So to get my example to build, it would be necessary to fix the FregeAndroid wrappers or write new wrappers.

how do I compile a whole Frege source tree

Following the answeres to how to use multiple inline assertions in Frege I learned how to compile two Frege modules A and B where B depends on A: you have to compile B. If given the -make option, the compiler will figure out that B depends on A, will find A on the sourcepath (-sp flag), and will compile A first and then B.
However, I cannot just give all files I care about to the compiler. Giving both A and B to the compiler failed with a "cyclic dependency" error for me. And I also found no way to give a directory to the compiler (it just did nothing).
This looks like I had to know the root of the dependency graph to do a proper compilation of all need-to-be-compiled files. But
I may not know the root.
There may be many of them.
It's very difficult to do a proper build automation that way.
Is there a combination of compiler options where I can just let the compiler compile all files in a source tree?
This issue has now been addressed by the frege-maven-plugin:
https://github.com/Frege/frege-maven-plugin
which is available in maven central.
EDIT: With more recent compiler releases, you can indeed compile whole trees:
java -jar fregec.jar -d classes/ -make directory1/ directory2/
Insofar, the answer below is obsolete.
The short answer is "no".
The long answer:
If you have an application, you should know the roots, it's the modules that contain main functions. One can compile all of them at once with the -make option, as long as they do not depend on each other.
In case of libraries, you could create a pseudo module that just imports all modules that belong to the library and compile that one.
If none of the above helps, and you simply need to compile "all that is there", you can do so by just passing all file names with the -make option (see below). The downside is that some files may get compiled twice.
The Frege builder of the eclipse plugin does compile all files in the correct order on a full build.
It would seem that such functionality is needed also for the command line compiler.
By the way, I couldn't retrace your "cyclic dependency" error. I used the following command:
java -jar ~/frege/fregec.jar -d bin -make -sp Real_World_Frege-master/ $(find . -type f -name '*.fr' -print)
In fact, this error should only be flagged in the case that A imports B while B (or something that B imports) imports A.

Compile-time wildcards in cmake install targets

I'm new to cmake and I'm finding it very frustrating. I am trying to use wildcards in file paths that are evaluated when the build runs, not when the build is generated.
I have created a build that uses SWIG to generate Java wrappers for some C++ code. I can write the commands to generate the native code, compile it, and produce a working shared library, and even use the INSTALL command to install that shared library correctly. What I can't figure out how to do is to write an INSTALL command that can copy all *.java files generated by SWIG into that same install location.
It seems that cmake's FILE GLOB command does the globbing when cmake is executed, and not when the build actually runs. Of course, when cmake is executed, SWIG hasn't run yet, and the Java files don't exist.
Is there a way to do what I want? Am I going about things wrong? It seems like this is such a fundamental part of what Makefiles need to do, I'm really surprised not to find an easy way to do it.
Assuming that the Java wrappers are located in the current binary directory, you can use the following install command to copy the Java files upon install:
install(
CODE "file( GLOB _GeneratedJavaSources \"${CMAKE_CURRENT_BINARY_DIR}/*.java\" )"
CODE "file( INSTALL \${_GeneratedJavaSources} DESTINATION \"$ENV{HOME}\" )"
)
The CODE form of the install command is used to execute two CMake commands upon running the install target. The first one collects all generated Java files in a helper variable. The second one uses the INSTALL form of the file command to copy the files.
you can use install(SCRIPT swigInstaller.cmake) or install(DIRECTORY) both of which supports doing file globing at install time. You can read more about the install command at:
http://cmake.org/cmake/help/cmake-2-8-docs.html#command:install