I have an example bazel project that I want to package as tar (to further distribute through homebrew etc...). The project consists of some python files, and a a run shell script.
When trying to use rules_pkg, I run into the following problem - the run script, b.sh, depends on #bazel_tools/tools/bash/runfiles/runfiles.bash to resolve the location of the binary package. #bazel_tools is not provided by default when using #rules_pkg.
What would be the correct approach for creating a distribution of the project above?
Related
I am working with application developed by Gupta, this Application is divided by 9 modules, For building .exe file from each .app file, I can do it easily via
Project > Build
I am repeating the above steps for each module.
Is there smart way for building all EXEs with one click as one bat file?
Appreciate any help.
You can build Gupta source code with command line:
If you want to compile to .exe then use
cbi63.exe -b "sourcefile" "destinationfile"
in your case this is something like
cbi63.exe -b "ktonline.app" "ktonline.exe"
If you want to compile to .apd use
cbi63.exe -m "sourcefile" "destinationfile"
This works with all Gupta versions. You just have to adjust cbiXXX.exe to your IDE version (e.g. cbi71.exe).
I provide a Yocto SDK to cross-build an application for an embedded target. The application itself is built using CMake. The SDK setup script provides many necessary environment variables (like location of the cross-compiler, sysroot, etc.), which so far was enough to build the application.
However, since recently the application has a dependency to the Boost library (through the command find_package(Boost REQUIRED) in the CMakeLists.txt). Now CMake complains that it cannot find the library, even though it's installed in the SDK sysroot. But if I build the application directly in Yocto, it works fine.
After some research it turned out that Yocto generates a toolchain.cmake file which is added to the cmake call. In this file, the variable CMAKE_FIND_ROOT_PATH is set, which CMake needs to find libraries. Using such a toolchain file, I can also build using the SDK.
Now I'm wondering if Yocto provides any mechanism to export such a toolchain file with the SDK. Or alternatively if the SDK provides a script or something to automatically create a toolchain file directly on the SDK build host.
Or shall I just tell the users of the SDK to manually create a toolchain file and add it to their cmake call?
Assuming that you're using the image based SDK, i.e. building it with bitbake <image> -c populate_sdk, adding the following toimage.bb should fix it:
TOOLCHAIN_HOST_TASK += "nativesdk-cmake"
That should give you a OEToolchainConfig.cmake file in the SDK. After sourcing the SDK environment file, cmake will be an alias to cmake -DCMAKE_TOOLCHAIN_FILE=$OECORE_NATIVE_SYSROOT/usr/share/cmake/OEToolchainConfig.cmake to further help your developers.
I'd like to add to Anders answer that while it worked great for me to add nativesdk-cmake this way it did not work when I tried to add nativesdk-python3-numpy. After some googling I found this, suggesting that TOOLCHAIN_HOST_TASK has to be extended using _append instead of +=.
I am looking for an example where is shown how to include an own library into the toolchain.
Let's call the library "myLib". For it I created an recipe "myLib.bb" and added:
BBCLASSEXTEND = "native nativesdk"
In my "local.conf" I added:
IMAGE_INSTALL_append = " myLib"
When building the SDK by:
$ bitbake myTarget -c populate_sdk
It produces a installer for the SDK and two manifest files. "myLib" is only included at the target manifest and not on the host. How can I include myLib on the host system?
The idea is, that a other person can build software on his system without the Yocto system. Only by using the toolchain he can generate binaries, which can be transferred and executed at the evalboard.
As long as your library myLib is installed into the image, it's supposed to be part of your generated SDK. Which you also say that it is, at least as part of the target manifest.
Ensure that you install the required header files for your library, then you should be able to cross-compile against your library.
Do you need to use myLib on the developers build machine? Otherwise, why do you want to have it added to the nativeskd part? (I.e. the host manifest). This is for applications that needs to run on the host machine, i.e. the cross-compiler, code generators etc.
I downloaded some code which contains some source code and some txt files.
The Read me or Installation file says following,
NBIS Open Source Software Installation Guide
(For LINUX and MAC OSX)
----------------------------------------------
Step 1:
Run the following command to setup your build environment:
./setup.sh <TARGET INSTALLATION DIR> [--without-X11]
[--STDLIBS] [--without-OPENJP2] [--32 | --64]
<TARGET INSTALLATION DIR> is replaced by the specific directory path
where you want to install the NBIS applications, libraries,
pre-computed runtime data and manuals.
Option Usage :
--without-X11 Build without X11 support.
--STDLIBS Build without JASPER, OpenJP2 and PNG
image format support.
--without-OPENJP2 Build without OpenJP2 image format
support.
--32 Build on 32-bit architecture machine.
(Only applicable for LINUX build.
If you are compiling on a 64-bit
machine, please have the proper
32-bit libraries installed.)
--64 Build on 64-bit architecture machine
(Only applicable for LINUX build.)
Example:
> ./setup.sh /SRC/NBIS/Main --32
Step 2:
Run the following commands to build "NBIS":
make config
make it
Step 3:
Run the following command to install NBIS executables into the
directory:
make install LIBNBIS=[yes|no]
Step 4: (OPTIONAL)
Run the following command, if you want to generate a list of
API supported in NBIS.
make catalog
Note: If you enable the "LIBNBIS=no" option during make install,
it will create the following libraries:
liban2k.a libclapck.a libfft.a libioutil.a libmindtct.a
libnfseg.a libpcautil.a libutil.a libbozorth3.a libf2c.a
libihead.a libjpegb.a libmlp.a libopenjp2.a libpcax.a
libwsq.a libcblas.a libfet.a libimage.a libjpegl.a libnfiq.a
libpca.a libpng.a libz.a
If you enable the "LIBNBIS=yes" option during make install, it will
combine all the libraries listed above and build libnbis.a.
Can I use the library build using above in my xCode project for iOS.
Thank You,
Subhash
I have an ios project that builds with CMake 3.1.1, but I am stuck on the last problem - getting CMake to copy the asset directory into the right location for the app.
I have this, which works when running the app in the simulator. However, it does not work, and in fact causes a build failure when archiving because the destination directory it constructs does not exist.
get_target_property(APPLICATION_BIN ${APPLICATION_NAME} LOCATION)
get_dotapp_dir(${APPLICATION_BIN} APPLICATION_APP_LOCATION)
add_custom_command(TARGET ${PROJECT_NAME}
POST_BUILD
COMMAND cp -r "${CMAKE_SOURCE_DIR}/assets" "${APPLICATION_APP_LOCATION}")
The directory I am copying has many subdirectories and I need them all preserved. Essentially I want to accomplish with cmake the same thing that happens when I drag the "assets" folder into the ios project underneath "Resources".
Use ${CMAKE_COMMAND} -E copy_directory instead of calling cp.
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${LOCATION_FOR_THE_APP} DEPENDS "${PROJECT_SOURCE_DIR}/assets" COMMAND -E copy_directory ${PROJECT_SOURCE_DIR}/assets ${CMAKE_CURRENT_BINARY_DIR}/${LOCATION_FOR_THE_APP})
add_custom_target(${CMAKE_CURRENT_BINARY_DIR}/${LOCATION_FOR_THE_APP} DEPENDS
My solution to this is similar to this answer. The goal of my project was to get googletests running on a cross-platform library, in which I had to wrap googletests into an XCTest Bundle. The build tool we are converting to is CMake for obvious reasons.
I ended up doing this as a pre-build step:
add_custom_command(TARGET ExampleTestTarget PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_LIST_DIR}/resources $<TARGET_FILE_DIR:ExampleTestTarget>
)
Essentially, at prebuild, CMake will copy everything in the resources folder into the root of the target's bundle. For some reason (probably a CMake thing), XCode picked these resource files up with no issue, so I didn't have to set the files to be RESOURCE files explicitly.
If you're using MacOS Bundles/Packages/etc., you'll have to copy-paste these files into $<TARGET_FILE_DIR:ExampleTestTarget>/Resources instead since this is the default resource location for MacOS xcodeproj's generated by CMake. (There are so many loopholes to get XCTests working in CMake that I advise everyone doing cross-platform gtests to create an executable instead for MacOS so you won't get into any trouble like this anyway).
Note, you won't see the files in XCode unless you add the files in target_sources(), but who cares... it works anyway! Who develops C++ exclusively in iOS? ....