I have a project that I'm running through the Jenkins CI server and is being built using the Cmake plugin, and I am consistently getting the same error:
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/580152/Celero/build/64
ERROR:Failed to get CMAKE_MAKE_PROGRAM value from C:\Users\580152\Celero\build\64\CMakeCache.txt
I am using Visual Studio 2012, and I can build and run the .sln file in Visual Studio using the files generated by the Cmake plugin. However, it never builds or finishes whenever I use the Cmake plugin. I've worked with Jenkins a bit in the previous weeks, but I'm still a noob when it comes to some of the plugins and settings, and the same goes to Cmake.
Is this a Jenkins plugin problem, a Cmake error, or am I just not setting something up right/missing the problem entirely?
Any and all help is much appreciated.
Update:
I have found that this error is caused by Cmakebuilder plugin, and was updated to fix this issue in version 2.1, and though I'm currently using that version of the plugin the error is still occurring. Could something have happened that my version was not updated properly (though it says that no updates are available) or is this an issue with the plugin that must be resolved?
Thanks again for any help.
Perhaps my experience is old, but I have had trouble with the Jenkins cmake plugin. So I prefer to do my Jenkins cmake builds with a command shell batch script. This also makes the Jenkins build job more closely match my development build. I try to have my Jenkins build jobs be little more than
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=../exports ..
cmake --build . --config Release --target test
cmake --build . --config Release --target install
Related
Started encountering this issue after pushing changes which has nothing to do with the node_modules or the deployment pipeline.
This issue is also seen when trying to rerun an already successful deployment in bitbucket.
I even tried updating the some of the packages to the latest version, but it still throws the same error.
But locally in my pc I have no issue with npm run build.
When the bitbucket pipeline is run.
The docker first installs node_modules using the npm install cmd.
After this while running npm run build the pipeline is failing with the error shown in the image above.
So I suspect it is the packages in the node_modules that are newly getting downloaded, because locally I have no problem with the build cmd.
Could anyone help me out, whether it is the incompatibility between the npm packages or the pipeline itself, Or if there might be any other error.
Thank you
Thanks to #Nitheesram Rajes I was able to fix this issue by updating typescript package using the command
npm install --save-dev typescript#latest
I am trying to build an iOS app that is exposed to a fairly extensive Rust project, but I am having issues with one of the dependencies in the project. The Rust project has a ZMQ dependency, and while I am able to build the project on my Mac, when I try to incorporate the Rust project I get the following error:
error: failed to run custom build command for `zmq-sys v0.8.3`
Caused by:
process didn't exit successfully: `/Users/lisa/company/project/project_detail/target/debug/build/zmq-sys-16dfc88dff84d855/build-script-build` (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=LIBZMQ_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64-apple-ios
cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64_apple_ios
cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-apple-ios
cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_apple_ios
cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-apple-ios
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_apple_ios
cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
--- stderr
thread 'main' panicked at 'Unable to locate libzmq:
pkg-config has not been configured to support cross-compilation.
Install a sysroot for the target platform and configure it via
PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
cross-compiling wrapper for pkg-config and set it via
PKG_CONFIG environment variable.', /Users/lisa/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.3/build.rs:31:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
I am trying to build the appropriate library for the iOS and iOS simulator architectures without relying on pkg-config, but if someone can provide useful instructions for configuring pkg-config for cross-compilation, I am not opposed to it, I just don't know how and can't find any up to date resources.
I have cloned the libzmq project from this github: https://github.com/zeromq/libzmq.git, then navigate into libzmq.
Inside libzmq, I run ./autogen.sh followed by ./configure --prefix [directory location] --target "aarch64-apple-ios", then make and make install.
The above procedure without the --target flag is how I got the project to compile on my Mac in the first place, and with the target flag in place make and make install both complete successfully, but when I try to build the project using PROJECT_DIR="${PWD}/ProjectName" ./ProjectName/build-rust.sh,
I get the previously posted error.
I am following the Swift-Bridge Book (https://chinedufn.github.io/swift-bridge/building/xcode-and-cargo/index.html) to try to load the Rust libraries into Xcode.
One thing to note: In the libzmq git hub, there is a folder called builds/ios/ and inside this folder is what looks to be a build file for all of the iOS archs, but I haven't been able to get the repo to build with that file. I think figuring out how to use the build_ios.sh build file as opposed to the standard build.sh provided might be the answer, but I've tried dropping build_ios.sh where build.sh is, and ./autogen.sh doesn't work, because it complains that it can't find configure.ac, even though this file does exist.
I'm trying to build the "latest" version of Appium Desktop from source (on a Mac), but I'm clearly not doing something that I need to be doing, because no binary is generated after I run all the build commands.
So, I've downloaded and unpacked the .zip archive https://github.com/appium/appium-desktop/archive/v1.16.0.zip, opened up a terminal session inside the root of the source directory, and followed the online instructions for building from source--but I think this is for the server build https://appium.io/docs/en/contributing-to-appium/appium-from-source/#running-appium-from-source
npm install
npm run build
node .
And it all appears to work successfully! I get a "build completed" message and life looks fab, but nothing launches as far as an app is concerned, and I can find no .app file anywhere in the source directory. And, oddly, there are no build instructions to be found anywhere in the source directory. There's a "ReadMe.md" file but it provides no instructions on how to build from source.
Can someone please tell me what I need to do to build and launch Appium Desktop (not the server) from source? (Oh, I also ran appium-doctor and it gave me a clean bill of health.)
Any feedback would be most appreciated!
Thanks,
Wulf
You've already run npm install so it should be as simple as running npm run dev if you want it in dev mode or npm start if you want non-dev.
See the Contributing to Appium Desktop readme for more.
I am using below configuration and trying to make Jenkins build but I am getting errors.
Note, I am able to make build successfully with command line.
My PC environments:
OS: ubuntu 14.04
Gradle version: 2.14.1.
Jenkins version: 2.25
Java version: java-8-openjdk-amd64
JENKINS BUILD ERRORS:
[workspace] $ /bin/sh -xe /tmp/hudson2322559356105735311.sh
+ cd /home/ekambaramv/Jenkins/workspace/CARMODE_STAR_O-OS/MAIN/
+ export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/
+ GRADLE_USER_HOME=/home/ekambaramv/Jenkins/gradle-2.14.1/
+ /home/ekambaramv/Jenkins/gradle-2.14.1/bin/gradle clean build
**FAILURE:** Build failed with an exception.
* What went wrong:
Failed to load native library 'libnative-platform.so' for Linux amd64.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
Build step 'Execute shell' marked build as failure
Finished: FAILUR
E
I've had similar problems with the JNI libary when using Gradle. It's possible you might be using a version of the JNI library that is incompatible with Gradle.
Try going to the site: https://debian.pkgs.org/9/debian-main-amd64/libnative-platform-jni_0.11-5_amd64.deb.html and downloading the libnative-platform-jni_0.11-5_amd64.deb package onto your machine.
You can either open Nautilus and right click the .deb package and select 'Open with Software Install', or you can navigate the command line to the download directory and run the following:
sudo apt-get install ./libnative-platform-jni_0.11-5_amd64.deb
Next, check to see if Gradle still gives you the same "Failed to load native library..." error message as before by running:
gradle --version
If the problem persists, and you still get the error message, you might want to consider upgrading to a later version of Gradle. I was able to get this working on Gradle 3.2.1, but I know this method isn't always possible.
If you need to back out the changes, just run another sudo apt-get update, and the JNI libraries will be overwritten with the latest version once more.
One More Thing
I mentioned the libraries get overwritten the next time you update your system (apt-get, Software Updater). To prevent this, run the following command:
sudo apt-mark hold libnative-platform-jni
This will force the update software to overlook any later versions of the library. To turn this off, run the opposite command:
sudo apt-mark unhold libnative-platform-jni
I can not find proof that it's possible. After 40 hours of driving myself to insanity, I'm left with a situation where I cannot build the Localization project that supposedly builds a header file needed by the poorly named AllInOne project (which builds Xalan-C.lib, natch).
This library is software malpractice writ-large, I am desperate for an answer because it is a dependency in another library that I have no alternative to using.
I have managed to build Xalan-C version 1.11, compatible with the latest version of Xerces-C (v3.1.1), in Visual Studio 2010. I don't know if it is possible with earlier versions, however these are the steps I followed in order to build with version 1.11:
Xerces-C has to be built as a dynamic library to obtain the xerces-c_3_1D.dll file which MsgCreator.exe is dependent on.
Clone the github repository to obtain the source code of Xalan-C version 1.11.
Set the environment variables XERCESCROOT and XALANCROOT in windows (not in Visual Studio).
XERCESCROOT The Xerces-C/C++ installation directory
XALANCROOT The Xalan-C/C++ source directory
Open the Xalan-C solution in VS2010 and build the MsgCreator project.
Copy the xerces-c_3_1D.dll file from the Xerces-C build and place it in the Xalan-C build folder, the same folder where MsgCreator.exe is located.
Now it is possible to generate the "missing" header files (LocalMsgIndex.hpp and LocalMsgData.hpp) that are needed to build the "AllInOne" project.
Run MsgCreator.exe in cmd with the provided path to XalanMsg_en_US.xlf which is located in $(XALANCROOT)\src\xalanc\NLS\en_US and what method to use when building the locale messages.
MsgCreator.exe $(XALANCROOT)\src\xalanc\NLS\en_US\XalanMsg_en_US.xlf -TYPE=inmem
(I used -TYPE=inmem, but check to see what method is best suited for your solution)
The header files are now generated and located in the build directory (where MsgCreator.exe resides). Copy or move them to $(XALANCROOT)\src and they should now be able to be located.
Now build the XalanMsgLib project.
And the last thing to do before the final build is to handle the including of afxres.h in the AllInOne.rc file (located in $(XALANCROOT)\Projects\Win32\Res\AllInOne). Visual Studio Express edition does not contain the MFC library which contains the afxres.h header. I simply changed it to #include "windows.h" instead.
And now it should be possible to build "AllInOne" successfully.
I struggled with this also and this is my recipe (VS2015 but look up the cmake docs for other IDEs)
Note I was specifically targeting xerces 3.2.3 and xalan 1.12. Use git tag to get the versions you need
git clone https://github.com/apache/xerces-c.git
cd xerces-c
git checkout v3.2.3
mkdir build
cd build
cmake .. -BVS2015 -G "Visual Studio 14 2015" -A x64 -DCMAKE_BUILD_TYPE=Debug
cd VS2015
devenv xerces-c.sln /Build Debug /Project ALL_BUILD
Because I use this with another build process that expects things in a certain way:
(assume you set up a target dir env called XERCESBUILD with bin/lib child dirs)
copy src\Debug\*.dll %XERCESBUILD%\bin
copy src\Debug\*.lib %XERCESBUILD%\lib
Then for xalan
git clone https://github.com/apache/xalan-c
cd xalan-c
git checkout Xalan-C_1_12_0
mkdir build
cd build
set PATH=%PATH%;%XERCESBUILD%\bin
cmake .. -BVS2015 -G "Visual Studio 14 2015" -A x64 -DCMAKE_PREFIX_PATH=%JBCRELEASEDIR% -DXALAN_DEBUG=1 -DCMAKE_BUILD_TYPE=Debug -DXerce
sC_LIBRARY_DEBUG=%XERCESBUILD%\lib\xerces-c_3D.lib
cd VS2015
devenv xalan-c.sln /Build Debug /Project ALL_BUILD
Note the xerces-c_3D.lib is specifically the Debug build so remove the D when doing the Release build.