I've used Maven a few times before, but I'm new to Gradle. I'm using Intellij IDEA 14.0.2 on Mac OS X 10.10.1. I also have ruby with rails installed. "gem update" shows that I have the latest.
I also have brew & oh_my_zsh installed and the latest.
Ok back to my problem. My purpose is to change a small project from Maven to Gradle. I created a new module for Gradle with IDEA:
apply plugin: 'java'
sourceCompatibility = 1.5
version = '1.0'
repositories {
mavenCentral()
}
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.11'
}
The output when running is:
/bin/bash /Users/lucianirimie/BCD/bcd-remote-tests/Gradle/build.gradle
zsh:1: command not found: plugin:
/Users/lucianirimie/BCD/bcd-remote-tests/Gradle/build.gradle: line 3: sourceCompatibility: command not found
/Users/lucianirimie/BCD/bcd-remote-tests/Gradle/build.gradle: line 4: version: command not found
/Users/lucianirimie/BCD/bcd-remote-tests/Gradle/build.gradle: line 6: repositories: command not found
/Users/lucianirimie/BCD/bcd-remote-tests/Gradle/build.gradle: line 8: syntax error near unexpected token }'
/Users/lucianirimie/BCD/bcd-remote-tests/Gradle/build.gradle: line 8:}'`
Here is the content of my .zshrc file
# DISABLE_CORRECTION="true"
# Uncomment following line if you want red dots to be displayed while waiting for completion
# COMPLETION_WAITING_DOTS="true"
# Uncomment following line if you want to disable marking untracked files under
# VCS as dirty. This makes repository status check for large repositories much,
# much faster.
# DISABLE_UNTRACKED_FILES_DIRTY="true"
# Which plugins would you like to load? (plugins can be found in ~/.oh-my-zsh/plugins/*)
# Custom plugins may be added to ~/.oh-my-zsh/custom/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
plugins=(git)
source $ZSH/oh-my-zsh.sh
# Customize to your needs...
export PATH=$PATH:/Users/lucianirimie/.rvm/gems/ruby-2.0.0-p247/bin:/Users/lucianirimie/.rvm/gems/ruby-2.0.0-p247#global/bin:/Users/lucianirimie/.rvm/rubies/ruby-2.0.0-p247/bin:/Users/lucianirimie/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin
export PATH="$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting
export PATH="/usr/local/bin:$PATH"
[[ -sbrew --prefix/etc/autojump.sh ]] && .brew --prefix/etc/autojump.sh
# Set name of the theme to load.
# Look in ~/.oh-my-zsh/themes/
# Optionally, if you set this to "random", it'll load a random theme each
# time that oh-my-zsh is loaded.
ZSH_THEME="robbyrussell"
# Example aliases
# alias zshconfig="mate ~/.zshrc"
# alias ohmyzsh="mate ~/.oh-my-zsh"
# Set to this to use case-sensitive completion
# CASE_SENSITIVE="true"
# Uncomment this to disable bi-weekly auto-update checks
# DISABLE_AUTO_UPDATE="true"
# Uncomment to change how often before auto-updates occur? (in days)
# export UPDATE_ZSH_DAYS=13
# Uncomment following line if you want to disable colors in ls
# DISABLE_LS_COLORS="true"
# Uncomment following line if you want to disable autosetting terminal title.
# DISABLE_AUTO_TITLE="true"
# Uncomment following line if you want to disable command autocorrection
# DISABLE_CORRECTION="true"
# Uncomment following line if you want red dots to be displayed while waiting for completion
# COMPLETION_WAITING_DOTS="true"
# Uncomment following line if you want to disable marking untracked files under
# VCS as dirty. This makes repository status check for large repositories much,
# much faster.
# DISABLE_UNTRACKED_FILES_DIRTY="true"
# Which plugins would you like to load? (plugins can be found in ~/.oh-my-zsh/plugins/*)
# Custom plugins may be added to ~/.oh-my-zsh/custom/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
plugins=(git)
source $ZSH/oh-my-zsh.sh
# Customize to your needs...
export PATH=$PATH:/Users/lucianirimie/.rvm/gems/ruby-2.0.0-p247/bin:/Users/lucianirimie/.rvm/gems/ruby-2.0.0-p247#global/bin:/Users/lucianirimie/.rvm/rubies/ruby-2.0.0-p247/bin:/Users/lucianirimie/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin
export PATH="$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting
export PATH="/usr/local/bin:$PATH"
[[ -sbrew --prefix/etc/autojump.sh ]] && .brew --prefix/etc/autojump.sh
Executing a Gradle build requires the installation of Gradle, or the use of a the Gradle wrapper. Take a look at the Gradle docs for installation instructions. I do believe Gradle is available via Brew as well. With the gradle command properly registered on your path, you would build your project something like this (from the folder with the build.gradle file.
$ gradle build
Related
I am new in azure devops services, and i am trying to run a pipeline that process an asp.net core application.
I have a task for restoring the project dependencies. Its code is dotnet Restore
.
The piepeline fail on that command with this message :
1:5>C:\Program Files\dotnet\sdk\5.0.410\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(141,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 6.0. Either target .NET 5.0 or lower, or use a version of the .NET SDK that supports .NET 6.0. [D:\a\1\s\AspNetProjectOnDocker.csproj]
Done executing task "NETSdkError" -- FAILED.
1:5>Done building target "_CheckForUnsupportedNETCoreVersion" in project "AspNetProjectOnDocker.csproj" -- FAILED.
1:5>Done Building Project "D:\a\1\s\AspNetProjectOnDocker.csproj" (_GenerateRestoreGraphProjectEntry target(s)) -- FAILED.
1>Done executing task "MSBuild" -- FAILED.
1>Done building target "_GenerateRestoreGraph" in project "AspNetProjectOnDocker.csproj" -- FAILED.
1>Done Building Project "D:\a\1\s\AspNetProjectOnDocker.csproj" (Restore target(s)) -- FAILED.
AspNetProjectOnDocker is the name of my .net project
My Questions :
How to access to the folder : C:\Program Files\dotnet\sdk\5.0.410\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets specified in the error message above.
Thanks.
My Questions :
How to access to the folder : C:\Program
Files\dotnet\sdk\5.0.410\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets
specified in the error message above.
Answer to your question:
This is not a folder, it is a file. You can access it via the following YAML pipeline definition.
trigger:
- none
pool:
vmImage: windows-2019
steps:
- script: |
echo Check target file
C:
cd C:\Program Files\dotnet\sdk\5.0.410\Sdks\Microsoft.NET.Sdk\targets
more Microsoft.NET.TargetFrameworkInference.targets
displayName: 'Check target file'
# if you encounter some issue such as can't find directory, you can use the following method to check what happens.
# - script: |
# echo Check target file step by step
# dir
# C:
# dir
# cd Program Files
# dir
# cd dotnet
# dir
# cd sdk
# dir
# cd 5.0.410
# dir
# cd Sdks
# dir
# cd Microsoft.NET.Sdk
# dir
# cd targets
# dir
# more Microsoft.NET.TargetFrameworkInference.targets
# displayName: 'Check target file step by step'
Successfully get the file content:
I am trying to learn myself how to debug rakudo and nqp. So this is my first attempt:
cd $HOME/debug
git clone https://github.com/rakudo/rakudo.git
cd rakudo
perl Configure.pl --gen-moar --gen-nqp --backends=moar
make
make install # installs into ./install/bin
export PATH=${PWD}/install/bin:$PATH
export PATH=${PWD}/install/share/perl6/site/bin:$PATH
# Testing executable:
perl6 --version
# This is Rakudo version 2018.12-256-g9517c3779 built on MoarVM version 2018.12-36-g34fac5f4e
# implementing Perl 6.d.
#
# Now modifying an nqp file:
cd nqp
# Change a file: E.g. : vim src/HLL/Compiler.nqp
# I added a line after line 293 in src/HLL/Compiler.nqp:
# nqp::say("*** Debugging message: HLL::Compiler::command_eval() ***");
# and save it
make
make install
# Testing perl6 again..
perl6 --version
The last command now gives the following exception:
Unhandled exception: Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' (from 'src/Perl6/Pod.nqp')
at <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/Perl6/Pod.moarvm:<dependencies+deserialize>)
from src/vm/moar/ModuleLoader.nqp:47 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:load_module)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/Perl6/Actions.moarvm:<dependencies+deserialize>)
from src/vm/moar/ModuleLoader.nqp:47 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:load_module)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/Perl6/Grammar.moarvm:<dependencies+deserialize>)
from src/vm/moar/ModuleLoader.nqp:47 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:load_module)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/perl6/runtime/perl6.moarvm:<dependencies+deserialize>)
h
So I thought, maybe I need to run make on rakudo also:
cd ..
make
but here make fails with:
/home/hakon/perlbrew/perls/perl-5.29.3/bin/perl5.29.3 tools/build/check-nqp-version.pl /home/hakon/debug/rakudo/install/bin/nqp-m
/home/hakon/debug/rakudo/install/bin/nqp-m tools/build/gen-cat.nqp moar src/vm/moar/ModuleLoaderVMConfig.nqp src/Perl6/ModuleLoader.nqp > gen/moar/ModuleLoader.nqp
/home/hakon/debug/rakudo/install/bin/nqp-m --module-path=blib --target=mbc --output=blib/Perl6/ModuleLoader.moarvm \
gen/moar/ModuleLoader.nqp
*** Debugging message: HLL::Compiler::command_eval() ***
Confused at line 2, near "*** Debugg"
at gen/moar/stage2/NQPHLL.nqp:811 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:panic)
from gen/moar/stage2/NQP.nqp:921 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:comp_unit)
from gen/moar/stage2/NQP.nqp:782 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:TOP)
from gen/moar/stage2/QRegex.nqp:2300 (/home/hakon/debug/rakudo/install/share/nqp/lib/QRegex.moarvm:parse)
from gen/moar/stage2/NQPHLL.nqp:2031 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:parse)
from gen/moar/stage2/NQPHLL.nqp:1951 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:execute_stage)
from gen/moar/stage2/NQPHLL.nqp:1984 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:run)
from gen/moar/stage2/NQPHLL.nqp:1976 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:)
from gen/moar/stage2/NQPHLL.nqp:1971 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:compile)
from gen/moar/stage2/NQPHLL.nqp:1666 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:eval)
from gen/moar/stage2/NQPHLL.nqp:1889 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:evalfiles)
from gen/moar/stage2/NQPHLL.nqp:1849 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
from gen/moar/stage2/NQPHLL.nqp:1773 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:command_line)
from gen/moar/stage2/NQP.nqp:4135 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:MAIN)
from gen/moar/stage2/NQP.nqp:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:<mainline>)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:<main>)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:<entry>)
make: *** [Makefile:457: blib/Perl6/ModuleLoader.moarvm] Error 1
A Rakudo build is statically "linked" against libraries in the NQP build used to produce it, and therefore Rakudo will need to be rebuilt after modifying NQP. Hashing is used to ensure that the wrong version of a dependency is never used; if this situation was not detected, there's a high chance of extremely strange failure modes.
The second failure is because the Rakudo build uses some NQP scripts to preprocess some source files, which are then fed to the NQP of Perl 6 compiler. It uses > to redirect the output into a file. Therefore, your debug output will be redirected into that file, and then - since it is not valid source code - cause a build error. The solution is to always produce debug output on stderr instead, for example using note.
I have a set of third-party binaries that I am trying to put into a conan package. The binaries are in folders for the build configuration: Linux32, Win32, Win64, Win32.
I have been able to produce a conan package for the Win64 configuration using the following conanfile.py:
from conans import ConanFile
class LibNameConan(ConanFile):
name = "LibName"
version = "1.1.1"
settings = "os", "compiler", "build_type", "arch"
description = "Package for LibName"
url = "None"
license = "None"
def package(self):
self.copy("*", dst="lib", src="lib")
self.copy("*.c", dst="include", src="include", keep_path=False)
def package_info(self):
self.cpp_info.libs = self.collect_libs()
I run the following commands in powershell:
conan install
mkdir pkg
cd pkg
conan package .. --build_folder=../
cd ..
conan export name/testing
conan package_files libname/1.1.1#name/testing
For the Win64 this works as expected. When I repeat the steps with Win32 binaries I do not get a different hash for the package.
I have tried running:
conan install -s arch=x86
However, this still results in the package having the same hash as the x86_64 configuration.
How is the configuration supposed to be set for generating a package from preexisting binaries?
If you are just packaging pre-built binaries, you are fine without the package() method, that is only relevant when building from the recipe:
from conans import ConanFile
class LibNameConan(ConanFile):
name = "LibName"
version = "1.1.1"
settings = "os", "compiler", "build_type", "arch"
description = "Package for LibName"
url = "None"
license = "None"
def package_info(self):
self.cpp_info.libs = self.collect_libs()
Unless there is some important reason you want to package the sources too, do you want them to be able to debug your dependencies too? In that case, please condition it to the build_type.
However this could be mostly irrelevant for your question. As your package doesn't have dependencies and you are not using any generator either, you don't need a conan install, and the settings you use there, have no effect.
You have to specify the settings for your binary configuration when you package_files:
$ conan package_files libname/1.1.1#name/testing # using your default config
$ conan package_files libname/1.1.1#name/testing -s arch=x86 # 32 bits instead of 64
...
Probably the recommended way is to use profiles:
$ conan package_files libname/1.1.1#name/testing # using your default profile
$ conan package_files libname/1.1.1#name/testing -pr=myprofile2
The documentation got recently a re-write, you might want to check: https://docs.conan.io/en/latest/creating_packages/existing_binaries.html
Telegraf version: Telegraf v1.0.1
I have the following files:
/etc/telegraf/telegraf.conf
main config file (which you create/get for free while installing telegraf). This file doesn't have any [[output.<plugin>]] stanza in it but does have valid default inputs.xx plugins enabled.
/etc/telegraf/telegraf.d/1-company-output-plugin.conf
(This file has valid outputs.<pluginname> plugin).
/etc/telegraf/telegraf.d/telegraf-additional-inputs-plugins.conf
(this file has additional inputs.<pluginname> plugins that I want to keep separate from the main conf file).
Running sudo service telegraf status shows Telegraf is running [OK]! and log file /var/log/telegrag/telegraf.log (looks good too without showing any errors).
If I make any changes to one of the above configuration files, I want to test those changes made (before I restart telegraf), so I'm running the following commands with -test or --test option but I'm getting the following error:
ubuntu#jenkins:~/test_aks_dir$ telegraf --config /etc/telegraf/telegraf.conf -test
2017/01/10 22:45:48 E! Error: no outputs found, did you provide a valid config file?
ubuntu#jenkins:~/test_aks_dir$ telegraf --config /etc/telegraf/telegraf.conf --test
2017/01/10 22:45:51 E! Error: no outputs found, did you provide a valid config file?
As you see above, both optons -test or --test worked but also gave a valid error message above.
As the above error was for not providing any configuration stanza for [[outputs.<plugin>]], I provided another --config file paramter for the file which contains the outputs plugin stanza, but now it gave an error for the missing inputs. file:
ubuntu#jenkins:~/test_aks_dir$ telegraf --config /etc/telegraf/telegraf.conf --config /etc/telegraf/telegraf.d/1-company-output-plugin.conf --test
2017/01/10 22:48:30 E! Error: no inputs found, did you provide a valid config file?
ubuntu#jenkins:~/test_aks_dir$
Note: The above command didn't error for providing multiple --config <someConfigFile> parameter values.
The same error comes if I want to test any change in the 3rd file : (/etc/telegraf/telegraf.d/telegraf-additional-inputs-plugins.conf)
How can I test an individual or selective configuration file changes using telegraf assuming I have multiple files here: /etc/telegraf/telegraf.d/*.conf ?
this is not possible at the moment, the only way to do it would be to specify the entire config directory
Describe difference between these two command lines:
C:\xxxxx> cmake -help
Usage
$ cmake [options] <path-to-source>
$ cmake [options] <path-to-existing-build>
Specify a source directory to (re-)generate a build system for it in the
current working directory. Specify an existing build directory to
re-generate its build system.
The last description does not give me how to use the first, or the second.
Could you explain it to me?
When you use you do an in-tree build (cmake .), there is no difference.
When you do an out-of-tree build, there is a difference.
Suppose your project lives in ~/foo and your current directory is ~/foo/build
You have to run cmake .. for the first build. But for subsequent reconfigures, you can use cmake . because there is already a build there.
This command:
cmake [options] <path>
works as follows:
if <path> is not a valid (that is, already configured) CMake build directory, it is assumed to contain a CMakeList.txt. CMake will configure the current working directory as a build directory using <path>/CMakeLists.txt for source directory.
if <path> is a valid CMake build directory, the command reconfigures that directory using the source directory assigned when you first configured that build directory
So the common usage patterns are:
initial configuration:
mkdir my-build-dir
cd my-build-dir
cmake [options] my-source-dir
subsequent (re)configurations:
cmake [options] my-build-dir # current-work-dir is not important
alternative (initial) configuration using undocumented options:
cmake -Hmy-source-dir -Bmy-build-dir [options] # cwd is not important