I'm just on:
https://openjfx.io/openjfx-docs/#modular
trying to create a jar I can run on other systems (that do not have the javafx libraries as would happen with a non-developer layman user) and they've told me to use this:
dir /s /b src\*.java > sources.txt & javac --module-path %PATH_TO_FX% -d mods/hellofx #sources.txt & del sources.txt
What is mods/
Where is that supposed to be? Are they talking about out/ ?
The doc you have linked refers to this sample.
If you clone the sample, and follow instructions on how to compile and run the project, the first command can be divided in three parts:
dir /s /b src\*.java > sources.txt & \
javac --module-path %PATH_TO_FX% -d mods/hellofx #sources.txt & \
del sources.txt
The first part just gets all the Java files in the src path and adds that to sources.txt file:
C:\path\to\hellofx\src\module-info.java
C:\path\to\hellofx\src\hellofx\HelloFX.java
The second part calls the javac command (see reference) to compile the content of sources.txt, adding the required --module-path option to include the JavaFX modules, and also adding the output or destination -d option:
-d directory
Sets the destination directory for class files. If a class is part of a package, then javac puts the class file in a subdirectory that reflects the package name and creates directories as needed.
This means that we are going to compile hellofx.HelloFX.java into the directory mods/hellofx, resulting in:
C:\path\to\hellofx\mods\hellofx\module-info.class
C:\path\to\hellofx\mods\hellofx\hellofx\HelloFX.class
The third step will just remove the sources.txt file.
And now you can run your module:
java --module-path "%PATH_TO_FX%;mods" -m hellofx/hellofx.HelloFX
You can specify any directory for the output, of course, so you can change it to out or build for instance, but then make sure you modify it accordingly in the rest of the instructions.
Related
With gnatpro 19.1, I'm trying to add gnathub to my project and am wondering how to set dynamically Project_Version as in:
package Dashboard is
for Project_Version use #git --describe --tags#; -- this needs to be updated.
end Dashboard;
I can't think of any simple way to do it.
A solution would be to use a Makefile that would configure a .gpr.in file but it seems contrived to change my whole buildchain just to add a version to the sonar config.
A simple, not automated solution, is to call the project with another switch:
gnathub -P Foo.gpr --plugins sonar-config,sonar-scanner\
--targs:sonar-scanner -Dsonar.projectVersion=$(git describe --tags)
But this is not really usable.
Similar question is to add the option -Dsonar.branch.name=$(git branch). AFAICT, the package Dashboard, as per the documentation has no Switch switch.
Is there any solution other than passing the extra arguments or forking gnatdashboard?
The best solution seems to reside in automating this configuration with a tool like Make.
For example, one can define the following Makefile:
# This target runs all the plugins listed
# in the section Dashboard.plugins of your project’s gpr
# sonar-config and sonar-scanner shall not be listed therein.
analyzes:
gnathub -P project
# This uses gnathub API to get the object dir where sonar-config file will be generated
OBJECT_DIR = $(shell gnathub -P project --exec object_dir.py 2>/dev/null | tail -n 1)
SONAR_PROPERTIES = $(OBJECT_DIR)/gnathub/sonar/sonar-project.properties
PROJECT_VERSION = $(shell git describe --tags)
BRANCH_NAME = $(shell git rev-parse --abbrev-ref HEAD)
# Uses gnathub to generate sonar properties file.
# Replaces the projectVersion and add branch name
# (notice that, on sonar, the branch name shall not be specified on your "master" branch)
$(SONAR_PROPERTIES): analyzes
gnathub -P project --plugins sonar-config --incremental
#sed -i "s/\(sonar.projectVersion = \).*/\1$(PROJECT_VERSION)/" $#
ifneq ($(BRANCH_NAME), master)
#echo "sonar.branch.name = $(BRANCH_NAME)" >> $#
endif
sonar: $(SONAR_PROPERTIES)
gnathub -P project --plugins sonar-scanner --incremental
.PHONY: sonar analyzes
Where object_dir.py is:
#!/usr/bin/env python
import GNAThub;
print (GNAThub.Project.object_dir());
Then:
$make sonar
Would run the analyzes and update them with the correct version and branch name (if necessary) to the SonarQube server.
For building my target I have a list of prerequisites contained in a file list.txt and a script for generating this file generate-list.sh.
I need the script to be executed as first thing every time I invoke the make in order to have the list.txt updated and to give ti make the right list of prerequisites.
prebuild:
touch list.txt
.SECONDEXPANSION:
exe: prebuild $$(shell cat list.txt)
touch exe
<files in list.txt>:
<rules for generating these files>
In this way when I run make I first get an error from cat saying that list.txt does not exist, then list.txt is generated but since the cat failed the prerequisites contained in list.txt are not generated.
One method you could use, given that generate_list.sh must be executed at the very start every time, would be to explicitly execute it using the shell function. This would mean altering your makefile to something like
$(shell ./generate_list.sh > /dev/null)
.SECONDEXPANSION:
exe: $(shell cat list.txt)
touch exe
#echo $?
<files in list.txt>:
<rules for generating these files>
Executing this makefile produces
$ make
touch exe
deps.c test.c
where my generate_list.sh file contains
#!/bin/bash
touch test.c deps.c
echo deps.c test.c > list.txt
echo 'Created prerequisites list.'
Notes
/dev/null is included in $(shell ./generate_list.sh > /dev/null) incase your generate_list.sh produces an output as this would cause an error in make of
$ make
GNUmakefile:1: *** missing separator. Stop.
otherwise.
#echo $? shows that all of the prerequisites in list.txt are now included as prerequisites of exe.
Alternate Method Based on Auto Dependency Generation
What you are attempting to do is very similar to automatic dependency generation which can be accomplished using the -include directive in make. For future usage you may want to consider going down this route and altering your generate_list.sh script to create a makefile that can be included in your main makefile.
I am trying to build a software following some instructions on line.
cd app
mkdir -p build/Release
cd build/Release
cmake ../..
make installpyplusplus && cmake .
make .
My questions:
What does "../.." after cmake do or mean?
What is the significance of the dot after make?
what will 'make installpyplusplus && cmake .' ?
The cmake application looks for one file in special, called CMakeLists.txt.
So by running:
cmake ../..
It's like saying to cmake that the CMakeLists.txt is two directories below, like described by MERose.
The cmake command creates many files at your current working directory (CWD, the directory you ran the command from), and among them is a file called Makefile, which has rules about which files to compile/build/copy/write/whatever and how to do it.
So when you run:
make .
You are telling the make application that the Makefile file is at your CWD. It's the same as running:
make
That looks for the Makefile file at your CWD.
Concluding, . is the CWD, and .. is one level below.
EX: If your CWD is /Users/yourname/
. represents /Users/yourname/
.. represents /Users/
../. represents /Users/
../.. represents /
And so on...
what will 'make installpyplusplus && cmake .' ?
When you use && the commands will be executed sequentially if the first command returns true (exit status zero). So, in the case you said, make installpyplusplus will be run, and after it's done (it can create a CMakeLists.txt, I don't know what you are running), if it returns true, the command cmake . will be run, and if the CMakeLists.txt is there, it will run properly.
BONUS:
If you run:
make -j4
You will separate the build process in 4 instances (you can change 4 by anything you want)! Multi-threading magic will make it build faster if you have more than one processor core available :)
I am trying to compile a simple Hello World from windchill shell using command javac com.A.B.Test.
But it is displaying could not find main class error.
I think your problem is Java and not Windchill related.
Let's say your Java source file is stored in the following location:
/src/com/A/B/Test.java
To compile that file in shell (Linux for example):
cd /src
javac com/A/B/Test.java
To run that file (if it contains a main method):
java -cp /src com.A.B.Test
Try using the below command from the windchill Shell.
Hope you are following the default file structure provided by the Vendor i'm providing the same below otherwise just edit the path mentioned in the below command.
javac -d codebase -cp %CLASSPATH%;%WT_HOME%\srclib\tool\Annotations.jar src*.java
First Go to Windchill Shell then navigate to the folder where java file is present. At that location type javac Test.java and press enter.
Put the code into WT_HOME/src/com/package, than run from WT_HOME:
ant -f bin/tools.xml class -Dclass.includes=com/..path-to-package/*
I am using cmake to build my project. For UNIX, I would like to type make from my project's root directory, and have cmake invoked to create the proper Makefiles (if they don't exist yet) and then build my project. I would like the cmake "internal" files (object files, cmake internal Makefiles, etc.) to be hidden (e.g. put in a .build directory) so it doesn't clutter my project directory.
My project has several sub-projects (in particular, a library, a user executable, and a unit test executable). I would like Makefiles (i.e. I type make and this happens) for each sub-project to execute cmake (as above) and build only that sub-project (with dependencies, so the library would be built from the executables' Makefiles, if needed). The resulting binary (.so library or executable) should be in the sub-project's directory.
I made a Makefile which does the main project bit somewhat well, though it feels somewhat hackish. I can't build specific targets using it, because my Makefile simply calls make in cmake's build directory.
Note that because the library is a sole dependency (and probably doesn't need to be build manually, and because I'm lazy) I omitted it in my Makefile.
BUILD_DIR := .build
.PHONY: all clean project-gui ${BUILD_DIR}/Makefile
all: project-gui project-test
clean:
#([ -d ${BUILD_DIR} ] && make -C ${BUILD_DIR} clean && rm -r ${BUILD_DIR}) || echo Nothing to clean
project-gui: ${BUILD_DIR}/Makefile
#make -C ${BUILD_DIR} project-gui
#cp ${BUILD_DIR}/project-gui/project-gui $#
project-test: ${BUILD_DIR}/Makefile
#make -C ${BUILD_DIR} project-test
#cp ${BUILD_DIR}/project-test/project-test $#
${BUILD_DIR}/Makefile:
#[ -d ${BUILD_DIR} ] || mkdir -p ${BUILD_DIR}
#[ -f ${BUILD_DIR}/Makefile ] || (cd ${BUILD_DIR} && cmake ${CMAKE_OPTS} ..)
If it helps, here's my project structure (if this is "wrong" please tell me -- I'm still learning cmake):
project/
project/CMakeLists.txt
project/common.cmake
project/Makefile -- see Makefile above for this; should be replaced with something better, building libproject, project-gui, and project-test
project/libproject/
project/libproject/CMakeLists.txt
project/libproject/libproject.so -- after build
project/libproject/Makefile -- doesn't exist yet; should build libproject only
project/libproject/source/
project/libproject/include/
project/project-gui/
project/project-gui/CMakeLists.txt
project/project-gui/Makefile -- doesn't exist yet; should build libproject then project-gui
project/project-gui/source/
project/project-gui/include/
project/project-test/
project/project-test/CMakeLists.txt
project/project-test/Makefile -- doesn't exist yet; should build libproject then project-test
project/project-test/source/
project/project-test/include/
If you haven't caught on yet, I'm basically looking for a way to build the project and sub-projects as if cmake wasn't there: as if my project consisted of only Makefiles. Can this be done? Is the solution elegant, or messy? Should I be trying to do something else instead?
Thanks!
If cmake is generating the makefiles, you can simply include the generated makefile in the master makefile, eg
# makefile
all: # Default
include $GENERATED
$GENERATED:$CMAKEFILE
# Generate the makefile here`
The included files are generated then make is restarted with the new included files. The included files should detail the targets, etc.
You should be able to change the location of used files using the vpath directive, see e.g. the Gnu make manual,
vpath %.o project/.build
else the tedious way is to rewrite the rules making note of the necessary directory.
Ed:
Perhaps we shouldn't use a flat makefile.
Try something like:
# makefile
all: gui test
clean:
$(MAKE) -f $(GUI-MAKE) clean
$(MAKE) -f $(TEST-MAKE) clean
gui:$(GUI-MAKE)
$(MAKE) -f $(GUI-MAKE) all
$(GUI-MAKE):$(GUI-CMAKE)
# Generate
# Same for test
This should work if the $(MAKE) -f $(GUI-MAKE) all command works on the command line, and we've hidden cmake in the generating target. You would have to copy any other targets to the master makefile as well, and take care running make in parallel.
Propagating object files through should involve something like
%.o:$(GUI-MAKE)
$(MAKE) -f $(GUI-MAKE) $#
although you'll probably get errors trying to make test objects