I've cloned the nixpkgs repo. From the top of that repo, I can run nix-build -A waf to build waf, and nix-env -f . -iA waf to make waf part of my user environment. Neither complains -- but afterward I am still unable to call waf:
[jeff#jbb-dell:~/nix/nixpkgs]$ waf
waf: command not found
[jeff#jbb-dell:~/nix/nixpkgs]$
Most packages, when I build them using nix-build -A, produce a symlink called result that goes to a folder containing the executable in question. Strangely, though, in waf's case the symlink is to a file, not a folder.
I'm running NixOS. If I add waf to environment.systemPackages in my configuration, upon building I get an error that seems to be a result of the strangeness described in the previous paragraph:
[jeff#jbb-dell:~/nix/jbb-config]$ sudo nixos-rebuild switch
building Nix...
building the system configuration...
these derivations will be built:
/nix/store/s618gllra3g2vn62c92advg9ks2swkz1-system-path.drv
/nix/store/gpph3adrgn949mikfvkwld86flshdbvq-unit-polkit.service.drv
/nix/store/i7xql7889ank54fnhd16zk4z79l1ix88-unit-systemd-fsck-.service.drv
/nix/store/dv9p4fsrqn1fwdvy9scyc7g9422wvm7c-dbus-1.drv
/nix/store/y730jf9s9nrzmkf55i01nlwinw5gxpsp-unit-dbus.service.drv
/nix/store/4wjan71p2di7lscnscdfhp55j49dcymx-system-units.drv
/nix/store/qrzwrpsz0hh5gzaxic6ww8mnwl03zwil-unit-dbus.service.drv
/nix/store/lhq0s9s5v3sqvjx6mqlyqj6hf4kv38sf-user-units.drv
/nix/store/hk5wbmf4dpna3dn0h0q1balj3482l6xd-etc.drv
/nix/store/yj3lfyv5sbp751xzy9jdw1d06n9gdiin-nixos-system-jbb-dell-19.09.1889.692a8cabbcc.drv
building '/nix/store/s618gllra3g2vn62c92advg9ks2swkz1-system-path.drv'...
The store path /nix/store/f1ylicjswpfx1wbvxapsnwy987qnlxl6-waf-2.0.18 is a file and can't be merged into an environment us ing pkgs.buildEnv! at /nix/store/kncarzyhspzsplkcmmyiqg2cavrwr373-builder.pl line 96.
builder for '/nix/store/s618gllra3g2vn62c92advg9ks2swkz1-system-path.drv' failed with exit code 2
cannot build derivation '/nix/store/yj3lfyv5sbp751xzy9jdw1d06n9gdiin-nixos-system-jbb-dell-19.09.1889.692a8cabbcc.drv': 1 dependencies couldn't be built
error: build of '/nix/store/yj3lfyv5sbp751xzy9jdw1d06n9gdiin-nixos-system-jbb-dell-19.09.1889.692a8cabbcc.drv' failed
[jeff#jbb-dell:~/nix/jbb-config]$
This looks like an implementation error to me. waf, as a top-level Nixpkgs package, should put its binary in $out/bin.
I've checked for usages of waf in nixpkgs and it seems to be used inside derivations only via wafHook.
If you only need waf inside a derivation, I recommend going with wafHook, following the example of other packages. If you need to install it in your user profile, ideally you can send a PR to make waf a proper package or you can work around it with a custom derivation.
Related
I am having problems generating client and server code for a GRPC service. I'm adapting the instructions at grpc.io.
There is a single protobuf file test_interface.proto defining my service and I've tried to build it with both of the following commands, run in the same path as this file:
protoc -I . --grpc_out=. --plugin=protoc-gen-grpc="C:\vcpkg\packages\grpc_x64-windows\tools\grpc\grpc_cpp_plugin" ./test_interface.proto
protoc -I . --grpc_out=. --plugin=protoc-gen-grpc=grpc_cpp_plugin ./test_interface.proto
Both of which result in the error:
--grpc_out: protoc-gen-grpc: The system cannot find the file specified.
I'm on Windows 10 and installed grpc v1.33.1 using vcpkg. This installs the development dependencies, but does not add their binaries to the system path. I've manually added the locations of protoc and grpc_cpp_plugin to the Path.
It's not clear to me which file it is failing to find, there were some syntax errors picked up earlier in test_interface.proto So I know this file is being opened okay. I can also run grpc_cpp_plugin from the command line without any problems.
Does anyone know why this is failing to build the client and server code?
make sure to add .exe to your plugin path like so: C:\vcpkg\packages\grpc_x64-windows\tools\grpc\grpc_cpp_plugin.exe
There's a note about this in our docs here:
https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.compiler.plugin
I’ve been trying to explore WSO2 Microgateway and set up a Microgateway project. Building the project in Windows 10 with the command “micro-gw build project-name” is giving this error: “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”.
I’ve downloaded the Toolkit and Runtime from https://wso2.com/api-management/api-microgateway/. I've set the Path environment variable to the /bin directory of the Toolkit and Runtime extracted folders, but still the “micro-gw build project-name” command is giving error “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”. I’ve also cloned the source code from Github (https://github.com/wso2/product-microgateway/) which has the Main.java class and tried setting environment variables to its path.
I also tried setting the environment variables to the path where Toolkit batch file is present. I also followed the steps mentioned here, https://github.com/wso2/product-microgateway/#running-the-microgateway.
I'm assuming the Toolkit batch file (micro-gw) would execute the Main.java class coming up in the error.
These steps did not resolve the error. I'm new to Java based product, and I'm sure I'm missing something here.
Problem is with the init command not the build command. Init command is suppose to setup the TOOLKIT after the first use. It should extract the platform.zip file and copy all of the required resources to relevant places for you.
I hope you get the Project ___ successfully initialized message after running the init command. Just check $TOOLKIT_HOME/logs/ directory to see if there are any information on the log file.
If the log file also doesn't help, as a workaround, copy all the .jar files inside $TOOLKIT_HOME/lib/gateway/platform and $TOOLKIT_HOME/lib/gateway/cli to $TOOLKIT_HOME/lib/platform/bre/lib and try again, that should work.
Also please report this issue at https://github.com/wso2/product-microgateway/issues
My goal is to set jetty to run as a service and figured I should have it run in command line first. My current aim is to be able to run jetty from root path. Once that's done, I can then set the same command to run as a service via https://nssm.cc/.
The issue
The webapp I am deploying in this Jetty instance uses logback to manage it's logging <file>logs/app.log</file>
This works as expected.
C:\jetty>java -jar start.jar
This does not C:\>java -jar C:\jetty\start.jar. (Note the different cmd path). Jetty can't figure out correct paths for log files. After some testing, I was able to rectify the path issue but still jetty is complaining about not being able to find the log file, even though I see it exists. So, permissions issue perhaps? I go ahead and give everyone full read and write access to the entire folder. No dice, still the same error.
Command I run now
C:\>java -Djetty.base=C:\jetty -Duser.dir=C:\jetty -jar C:\jetty\start.jar but the error persists.
....
12:11:51,095 |-INFO in ch.qos.logback.core.FileAppender[FILE] - File property is set to [logs/app.log]
12:11:51,111 |-ERROR in ch.qos.logback.core.FileAppender[FILE] - Failed to create parent directories for [C:\jetty\logs\app.log]
12:11:51,111 |-ERROR in ch.qos.logback.core.FileAppender[FILE] - openFile(logs/app.log,true) call failed. java.io.FileNotFoundException: logs\app.log (The system cannot find the path specified)
at java.io.FileNotFoundException: logs\app.log (The system cannot find the path specified)
....
Jetty version is 9.4.9.v20180320
Create a proper ${jetty.base} directory, outside of of the ${jetty.home} directory.
Next, get yourself a fresh copy of jetty-home (or the jetty-distribution which really only adds documentation, demos, and sample bases to jetty-home).
http://search.maven.org/#search|gav|1|g:"org.eclipse.jetty" AND a:"jetty-home"
Unpack that jetty-home artifact into a fresh directory.
Important:
Don't touch any content in jetty-home
Don't edit anything in jetty-home
Don't remove anything from jetty-home
Don't add anything into jetty-home
Leave jetty-home alone
Treat jetty-home as a read-only directory
All above bullets apply even if using jetty-distribution
Lastly, start jetty per the recommendations in the Jetty Documentation.
> cd \path\to\myjettybase
> java -jar \path\to\jetty-home\start.jar
Note the lack of declared system properties for -Djetty.home and -Djetty.base, this is important!
This will set up the following important directory properties.
jetty.base will be your CWD, or \path\to\myjettybase
jetty.home will be where your start.jar was found, aka \path\to\jetty-home\
user.dir will be your CWD and point to \path\to\myjettybase
What's important, for logging configurations like yours, is the user.dir system property. (aka the current working directory)
The technique you are using where you don't pay attention to the working directory and just attempt to force values into the JVM with system properties is only viable in the simplest of projects and usecases. (your requirements have outgrown that kind of setup)
I'm working on a Makefile project on Visual Studio, modifying code from my laptop and remotely building on a Linux server which i connect to via ssh.
I configured my project Property pages as such:
General: https://i.stack.imgur.com/3WdP6.png
Debugging: https://i.stack.imgur.com/zI5ua.png
Remote Build > Build command line: cd $(RemoteProjectDir) && echo password |sudo -S make
In the remote project directory i have already every file of the project, Makefile too. When pressing Compile i expect VS to copy the changed code from the local directory, file by file, to the remote one, but the only error i get is this:
Linux.Makefile.Target(108,5): error : Cannot copy \foo\bar\file.cpp remotely to /home/user/projects/MyProject/file.cpp
At line 108 of the file with target extension there is this tag:
<CopySources
Sources ="#(FinalSourcesToCopyRemotely)"
AdditionalSources="#(AdditionalSourcesToCopyRemotely)"
ProjectDir="$(ProjectDir)"
RemoteProjectDir="$(RemoteProjectDir)"
RemoteTarget="$(ResolvedRemoteTarget)"
IntermediateDir="$(IntDir)"
RemoteProjectDirFile="$(RemoteProjectDirFile)"
UpToDateFile="$(CopySourcesUpToDateFile)"
LocalRemoteCopySources="$(LocalRemoteCopySources)">
<Output TaskParameter="ResolvedRemoteProjectDir" PropertyName="_ResolvedRemoteProjectDir" />
</CopySources>
Can this file be the cause of the problem for some reason? Is it good to tinker with a .targets file?
I've already remotely build another project before with same configurations and similar Makefile (adapted for paths and file names) and it worked just fine.
[EDIT]:i've added the command echo password| sudo -S make to interact with the password request prompted by sudo, this worked in the other project and i still get the error
You can't use sudo when debugging . So I'd guess you can't use sudo when building either. The problem is sudo prompts for a password and VSLinux can't handle that. One option is to configure sudo so it doesn't request a password but that's not advised. Can you change your setup so it doesn't require sudo?
Long story short: if you get this error, just create another project with the same exact property as the first one, that'll do.
The problem was probably due to the fact that I changed the property several times before using the right one, which could have created some configuration (-ish) file, unchanged after the modifications.
I need to run npm install && gulp build inside my static/semantic-ui folder, so it creates the needed css file.
I saw this example with Setup.hs, however on my scaffolded project I don't have it, so my question where is the right place to put the code to run those bash commands.
If you're using the default Yesod scaffolding (generated by stack tool), then it indeed doesn't contain Setup.hs (which is a bit weird, as their own guide - https://github.com/commercialhaskell/stack/blob/master/doc/GUIDE.md - recommends having it as a good practice)
Setup.hs should be located in main project directory (same where stack.yml and yourproject.cabal are located) and content should be roughly the same as in your included example (defaultMainWithHooks is the key part).
Details of hooks usage are specified in https://www.haskell.org/cabal/users-guide/developing-packages.html and in cabal spec: https://hackage.haskell.org/package/Cabal-1.24.0.0/docs/Distribution-Simple.html
BTW, for now stack doesn't support pre-build hooks on its own (for details see: https://github.com/commercialhaskell/stack/issues/503), so you have to stick to ones provided by cabal - that's where Setup.hs comes from.