I have given the following command at the bin directory of Izpack like this
C:\Program Files\IzPack\bin>compile D:\ant\guage install.xml
Is this the correct way to give ?
No, you are missing arguments. Please consult the getting started section in the IzPack online documentation for details.
Try the following command
compile install.xml -b . -o install.jar -k standard
install.xml is in bin folder. It will generate install.jar file.
To make exe file see this.
Related
Trying to compile the quick start example for GRPC.
It produces these errors:
CMake Error at /home/priya/grpc/examples/cpp/cmake/common.cmake:101 (find_package):
Could not find a package configuration file provided by "Protobuf" with any
of the following names:
ProtobufConfig.cmake
protobuf-config.cmake
Add the installation prefix of "Protobuf" to CMAKE_PREFIX_PATH or set
"Protobuf_DIR" to a directory containing one of the above files. If
"Protobuf" provides a separate development package or SDK, be sure it has
been installed.
Call Stack (most recent call first):
CMakeLists.txt:24 (include)
I have tried all the proposed solutions for this on other similar questions but to no avail. These are the solutions that did not work for me:
Changing find_package(protobuf CONFIG REQUIRED) to an uppercase find_package(Protobuf REQUIRED)
Installing pkg-config
This thread
I could not find any other solutions. Any help would be greatly appreciated.
So the problem is I am new with bash scripts. I had copied and pasted the instructions in quick start into a bash script so that we could integrate the gRPC repository into our repo smoothly without having to build manually each time.
This problem was caused by incorrectly calling the script, which meant the environment variable for the install directory was never getting set correctly and was remaining an empty value. You must put source before calling the file, e.g source ./grpcSetup.sh. Please read this other stackoverflow question that explains the problem more clearly.
It's likely to be caused by lack of submodules in the gRPC repo, I guess. Would you get submodules before build? You can run git clone --recurse-submodules -b v1.38.0 https://github.com/grpc/grpc for it, as an example.
Have you compiled and installed grpc before?
I get this cmake error today and I run make install in the directory of builded grpc and it works now.
While installing GRPC, a variable is set that points to installation folder of GRPC.
mkdir -p $MY_INSTALL_DIR
mkdir -p $MY_INSTALL_DIR
If we change name MY_INSTALL_DIR to other, then that has to changed in CMakeList.txt file , hence error. To avoid and to keep it simple just use same name as mentioned in documentation.
So I'm attempting my first Chrome build just for fun and I've gotten all the files I want through gclient config and sync. However, there are no project files that VS can open, just a bunch of .gyp files that are useless to me.
The command 'gclient runhooks --force' is supposed to generate the sln files for me, but when I run it I get nothing. Not even an error.
What's up?
Thanks.
Yes, this info still seems to be missing from the Chromium documentation at the moment. The way to generate your Visual Studio Solution files is:
export GYP_GENERATORS=msvs-ninja
gclient runhooks --force
You won't need the --force if it's your first time calling gclient runhooks. The generator should be good for your ninja build and it should generate your .sln files.
Yes, really annoying problem... I did all kinds of stuff to make it work, and this is how I made it work in the end, believe it or not:
Restart PC
In terminal cd to the dir containing .gclient file
checkout Important note below if you never used GYP before
gclient runhooks --force
profit
Important: You must also set environment variable named GYP_GENERATORS to a value listing build project types. For example, to generate NINJA build files and Microsoft Visual Studio (your case) do this if in linux terminal export GYP_GENERATORS=ninja,msvs or if Windows cmd setx GYP_GENERATORS ninja,msvs /M before step 4. This way you control what project types will be generated on runhooks.
I want to set up my Jenkins with Cobertura to track code coverage.
Unfortunately I can not generate a valid xml.
I'm using:
gcovr 2.5-prerelease (r2774)
Xcode 4.6.1 Build version 4H512
My project is generating code coverage files correctly, but the report created with gcovr is not useful.
The command I use to generate the report is:
gcovr -r /Users/Shared/Jenkins/Home/jobs/CodeCoverage/workspace
--object-directory /Users/Shared/Jenkins/Home/Library/Developer/Xcode/DerivedData/myProject-aooceqwwovrizceerghqvhflcfty//Build/Intermediates/myProject.build/Development/myProject.build/Objects-normal/x86_64
--exclude '.*Developer.*'
--exclude '.*Tests.*'
--xml
This will create me this output:
<?xml version="1.0" ?>
<!DOCTYPE coverage SYSTEM 'http://cobertura.sourceforge.net/xml/coverage-03.dtd'>
<coverage branch-rate="0.0" line-rate="0.0" timestamp="1364322914" version="gcovr 2.5-prerelease (r2774)">
<sources>
<source>
/Users/Shared/Jenkins/Home/jobs/CodeCoverage/workspace/Project/myProject/
</source>
</sources>
<packages/>
</coverage>
Additional Informations:
If I remove --object-directory and -r and then I execute the command from the derived data directory a valid report is generated. This report can be read from cobertura but can not show any detailed information about the source files.
When working with XCode, I've found that using $WORKSPACE/build as the build directory helps with this problem. This keeps the Derived Data directory out of it, and also neatly keeps my object files in the build directory. It also prevents two builds from interfering with each other.
If using the Xcode build tool, set SYMROOT to $WORKSPACE/build in the Tool's build configuration. If you're building from the command line, set it manually on the command line or in the environment.
Then a gcovr script such as:
/your/path/to/gcovr -r . --object-directory build/YourApp.build/Coverage-iphonesimulator/YourApp.build/Objects-normal/i386 --xml > build/coverage.xml
(your path may vary slightly depending on what you call your build style, etc.)
And finally in the Cobertura config, point at build/coverage.xml, and you should get annotated source when you use the tool within Jenkins.
Should do the trick. I've been really happy with that configuration on our small farm of Mac Minis.
gcovr should be executed from the folder where the .gcda and .gcno files exist. And the root path is the folder where the source files(.c or .cpp) exist.
With this, the command looks like something as shown below.
rr-mac:gcdaFolder$ gcovr -r /path_to_C_sourceFiles/ .
For output html file below command works
rr-mac:gcdaFolder$ gcovr --html -o Filename_rp.html -r /path_to_C_sourceFiles/ .
Note: The dot(.) at the end is mandatory
The gcovr python script does not appear to supports out of source tree builds.
I raised a bug report about this here https://github.com/gcovr/gcovr/issues/61
Had hoped that this would help, but getting a different error.
attempting to compile the following as hello.cs
using Gtk;
using System;
class Hello
{
static void Main()
{
Application.Init();
Window window = new Window("helloworld");
window.Show();
Application.Run();
}
}
Compiling with the following command "gmcs hello.cs -pkg:gtk-sharp-2.0"
depending on the command prompt, I'm receiving either cs0006 (mono cp) or cs2001 (win cp) saying that files cannot be found
from mono cp it says that the metadata file cannot be found
from win cp it says that source file cannot be found
Here's a sample:
c:\Users\Stephen Lloyd\Desktop>gmcs hello.cs -pkg:gtk-sharp-2.0
-r:C:/Program Files \(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/pango-sharp.dll \(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/atk-sharp.dll \(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/gdk-sharp.dll \(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/gtk-sharp.dll \(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/glib-sharp.dll
error CS2001: Source file `Files' could not be found
error CS2001: Source file `\(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/pango-sharp.dll' could not be found
error CS2001: Source file `\(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/atk-sharp.dll' could not be found
error CS2001: Source file `\(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/gdk-sharp.dll' could not be found
error CS2001: Source file `\(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/gtk-sharp.dll' could not be found
error CS2001: Source file `\(x86\)/Mono-2.10.8/lib/mono/gtk-sharp-2.0/glib-sharp.dll' could not be found
Compilation failed: 6 error(s), 0 warnings
In all cases the referenced .dlls are in that folder.
Any thoughts?
-pkg is broken on Windows; you will need to supply individual individual -r[eference]:s. Please see this answer for details.
As an alternative to manually entering references, I found it easier to just install mono to a path with no spaces aka C:\devtools\mono and then adding the ... C:\devtools\mono\bin to your path. The command was then successful for me. As an aside I have had a similar problem before with using unix devtools on windows and this has worked there as well.
Had this problem on MacOSX. The solution to add the mono bin directory to path solved it for me.
Specifically,
"/Library/Frameworks/Mono.framework/Versions/Current/bin"
needed to be on my path.
I did this:
export MONOPATH=/Library/Frameworks/Mono.framework/Versions/Current
export PATH=${PATH}:${MONOPATH}/bin
And afterwards, I was able to compile via:
gmcs /t:exe /debug+ -pkg:dotnet WinFormsHello.cs
(likewise for gtk# etc)
I was having the same problem running this on Windows 10. Since Windows supports symbolic links, since Vista, I thought this might be a solution ... it worked for me.
As Administrator, I created a directory symbolic link from the root directory to mono:
cd \
mklink /d mono "\program files x(86)\mono"
Then, again as Administrator, I edited the "Open Mono Command Prompt" shortcut properties:
Target: C:\Windows\SysWOW64\cmd.exe /k "C:\Mono\\bin\setmonopath.bat"
Start In: C:\Mono
Now when pkg-config parses the drive-path of mono.exe it "sees" only c:\mono and will proceed to append the rest of the path to resolve the required packages.
You can set your symbolic link from any directory. I set it from root for sake of simplicity. The main purpose is to establish a path without spaces or special characters.
Note: I'm using Mercurial as an example here, because that's what I'm trying to get to work with MSBuild right now.
But the problem is not limited to Mercurial, it happens with every external program that is somewhere in my %PATH% variable (I tried the same with PowerShell, for example).
So I didn't put the Mercurial tag on this question on purpose, because this is not about Mercurial!
What I actually want to do:
I want my build script to get the current revision number from my Mercurial repository and store it in a file.
The simplest way to do this from the command line is:
hg id -i >rev.txt
Mercurial is installed on my machine and the installation folder is in my %PATH% variable.
So I can run this line from anywhere on my machine (directly from the command line, or from a batch file), and it just works.
The problem occurs when I try to run this line from my build script.
I change the BeforeBuild (or AfterBuild) section of my .csproj file as follows:
<Target Name="AfterBuild">
<Exec Command="hg id -i >rev.txt"/>
</Target>
When I compile my solution with Visual Studio, it works and the rev.txt file is created in the folder where my .csproj is.
But when I compile the exact same solution from the command line with MSBuild, the build fails with the following error message:
The command "hg id -i >rev.txt" exited with code 9009.
I googled "msbuild code 9009" and found some solutions, but all of them propose to provide the full path to the executable.
When I do this, the build succeeds with MSBuild as well.
But this is not an acceptable solution for me, because I can't be sure that everyone using my project (including the build server) has installed Mercurial in the exact same folder.
That's exactly what %PATH% is for...
The same happens when I put the <Exec Command="... line directly into the build script.
If I specify the path to the executable, it works.
If I don't specify the path, it doesn't.
Is there any trick to make MSBuild execute programs in my %PATH% variable without specifying the complete folder?
EDIT:
#leppie:
Output redirection:
You mean the fact that I save the output of my command in a text file inside the command , instead of just running hg id -i as a command and using an output parameter or something like that to get the output?
Doesn't make any difference...the error is the same when I omit >rev.txt.
Command line args:
No, it throws the same error, even if I shorten the command to just hg (without any parameters).
Don't forget: if I run the exact same Exec command in the exact same .csproj file from Visual Studio, or if I just provide the path to the .exe file in the command, everything works.
So IMO output redirection and command line args can't be the problem.
Have you tried this extension pack for mercurial/msbuild?
http://msbuildhg.codeplex.com/documentation
Seems to have a task for returning revision id, which is what your trying to achieve no?
<HgVersion LocalPath="$(MSBuildProjectDirectory)" Timeout="5000">
<Output TaskParameter="Revision" PropertyName="AssemblyRevision" />
</HgVersion>
Okay, I found the solution.
I have to admit, it was a classic case of PEBKAC :-)
I'll explain it anyway, maybe it will help someone who made the same mistake:
Basically everything I have tried (plus what James Woolfenden suggested in his answer) would have been worked...if only the batch file that I use to run the build script wouldn't have looked like this:
path="%windir%\Microsoft.net\Framework\v4.0.30319"
msbuild build.proj
Yes, exactly.
I'm editing the %PATH% variable for the duration of this batch file, and I'm overwriting it with the path to MSBuild instead of just appending it.
So when my build script tries to call Mercurial, it can't find it anymore because its location is not in the %PATH% variable anymore.
No idea why I didn't see this before.
The correct way would be to append the MSBuild path, leaving the other paths intact:
path=%path%;%windir%\Microsoft.net\Framework\v4.0.30319