Im building my project with circleci 2 and in my test coverage im getting a weird error:
[info] Compiling 5 Scala sources to /root/build/target/scala-2.11/test-classes...
[error] /root/build/test/myApplication/SomeGeneratorNameGen.scala:40: File name too long
[error] This can happen on some encrypted or legacy file systems. Please see SI-3623 for more details.
[error] employeeName <- Gen.numStr
[error] ^
Your file length is
printf /root/build/test/myApplication/AmountPerExpTypeGen.scala | wc -c
56
$ printf /root/build/test/myApplication/ | wc -c
31
Based on the most of the references, you might want to increase the length using scalac options.
eg.
"-Xmax-classfile-name", "242"
Releated links
https://discuss.circleci.com/t/scala-sbt-assembly-does-not-work/10499/10
Filename too long sbt
https://github.com/sbt/sbt-assembly/issues/69#issuecomment-14176243
https://groups.google.com/forum/#!topic/simple-build-tool/wtD6vgdiy6g
https://issues.scala-lang.org/browse/SI-3623
Related
When building chisel using sbt, when run as a batch process, how do I turn off the progress bars etc. so that the output is clean like I get with most compilers?
That is, I like to build chisel using sbt from within a makefile, like this:
${VLOG_DIR}/${NAME}.v: ${NAME}.scala
setsid sbt \
'runMain ${NAME}.${NAME} --top-name ${NAME} --target-dir ${VLOG_DIR}'
However sbt/scala/chisel like to attempt to generate some sort of progress bars while building that emit terminal escape codes to attempt to update the output in place. When run inside my shell this does not work very well, but when run inside emacs it makes a huge mess:
make
setsid sbt \
'runMain HelloWorld.HelloWorld --top-name HelloWorld --target-dir Gen_HelloWor\
ld.verilog_dir'
^[[0m[^[[0m^[[0minfo^[[0m] ^[[0m^[[0mLoading project definition from /home/user/h\
ello-chisel/project^[[0m
^[[2K
^[[2K
^[[2K
^[[2K
^[[2K
^[[5A^[[2K
^[[2K
^[[2K
^[[2K
^[[2K
^[[2K | => hello-chisel-build / update 0s
^[[6A^[[2K
^[[2K
Especially when there is an error message:
^[[2K
^[[2K
^[[2K | => hello-chisel / Compile / compileIncremental 1s
^[[6A^[[2K^[[0m[^[[0m^[[31merror^[[0m] ^[[0m^[[0m/home/user/hello-chisel/HelloWor\
ld.scala:46:17: overloaded method value apply with alternatives:^[[0m
^[[2K
How do I turn all of that off and get normal looking output having clean error messages?
Short answer
Pass -no-colors to sbt on the command line, per the
sbt FAQ:
$ sbt -no-colors 'test:runMain gcd.GCDMain'
Despite the name "no colors", it suppresses all terminal escape stuff, including the progress bars.
Other alternatives
The option can also be spelled --no-colors (two hyphens), which is how it appears in the output of sbt --help (and sbt -help).
The same effect can be achieved by passing -Dsbt.log.noformat=true to sbt (or to java if invoking that directly) as indicated in this answer:
$ sbt -Dsbt.log.noformat=true 'test:runMain gcd.GCDMain'
It can also be achieved by setting the JAVA_OPTS environment variable to -Dsbt.log.noformat=true:
$ JAVA_OPTS=-Dsbt.log.noformat=true sbt 'test:runMain gcd.GCDMain'
If you are using sbt-launch.jar, then you have to use the -D switch because -no-colors is not recognized in that context (the sbt shell script is what recognizes -no-colors):
$ java -jar ~/opt/sbt-1.3.4/bin/sbt-launch.jar -Dsbt.log.noformat=true 'test:runMain gcd.GCDMain'
Finally, when sbt detects that its stdout is not a TTY, it will suppress color output:
$ sbt 'test:runMain gcd.GCDMain' | cat
That's not a good option in a Makefile though because you lose the exit status of sbt (without further shenanigans).
Unfortunately, sbt does not respect NO_COLOR.
Chisel output has some colors anyway
When using Chisel, for example the chisel template, even with -no-colors, some terminal escape codes appear in the output anyway:
$ sbt -no-colors 'test:runMain gcd.GCDMain' | cat -tev
[info] Loading settings for project chisel-template-build from plugins.sbt ...$
[info] Loading project definition from /home/scott/wrk/learn/chisel/chisel-template/project$
[info] Loading settings for project chisel-template from build.sbt ...$
[info] Set current project to chisel-module-template (in build file:/home/scott/wrk/learn/chisel/chisel-template/)$
[warn] Multiple main classes detected. Run 'show discoveredMainClasses' to see the list$
[info] running gcd.GCDMain $
[^[[35minfo^[[0m] [0.001] Elaborating design...$
[^[[35minfo^[[0m] [1.064] Done elaborating.$
Total FIRRTL Compile Time: 512.0 ms$
file loaded in 0.114380184 seconds, 22 symbols, 17 statements$
[^[[35minfo^[[0m] [0.001] SEED 1581769687441$
test GCD Success: 168 tests passed in 1107 cycles in 0.047873 seconds 23123.91 Hz$
[^[[35minfo^[[0m] [0.037] RAN 1102 CYCLES PASSED$
[success] Total time: 3 s, completed Feb 15, 2020 4:28:09 AM$
Note the [^[[35minfo^[[0m] output near the end. This happens because chiselFrontend/src/main/scala/chisel3/internal/Error.scala unconditionally prints color escape sequences (see the tag function), which is arguably a bug in Chisel since its output is clearly meant to look similar to sbt output.
Effect of setsid
In your example Makefile, you're invoking sbt via setsid. As far as I can tell, everything I've said applies equally to that circumstance. However, you probably want to pass --wait to setsid so it will wait for sbt to complete before exiting. In my testing, setsid will implicitly wait only when stdout is not a TTY, but I doubt you actually want that hidden variability.
I am trying to build a cross compiler for raspberry pi. I am using crosstool-ng to build this compiler. I am following this link for reference. I have made all configurations as told in the link. But when i tried to build, I am getting "CT_TARGET command not found" error. I tried googling about the error couldn't able to find any hits. Could someone help me in overcoming this issue? Here is the complete build output.
/opt/cross/bin$ sudo ct-ng build
/opt/cross/bin/.config.2: line 30: CT_TARGET: command not found
[ERROR]
[ERROR] >>
[ERROR] >> Build failed in step '(top-level)'
[ERROR] >>
[ERROR] >> Error happened in: source[/opt/cross/bin/.config.2#30]
[ERROR] >> called from: main[scripts/crosstool-NG.sh#25]
[ERROR] >>
[ERROR] >> There is a list of known issues, some with workarounds, in:
[ERROR] >> '/opt/cross/share/doc/crosstool-ng/ct-ng.1.21.0/B - Known issues.txt'
[ERROR]
[ERROR] (elapsed: 24087567:26.24)
make: *** [build] Error 127
It seems you made a mistake entering the configuration options.
You need to make sure that you put a $ symbol in front of CT_TARGET:
$CT_TARGET
or else it thinks it is a command that will return the value it wants.
Posting your exact config instead of the website you got the instructions from would provide much more details to solve your specific issue.
I am getting an error saying I have a file that is too long in sbt.
[info] Compiling 29 Scala sources to /home/chris/dev/suredbits-core/target/scala-2.11/classes...
[error] File name too long
[error] one error found
[error] (compile:compile) Compilation failed
[error] Total time: 7 s, completed Feb 17, 2015 8:10:25 AM
How do I find out which file is too long so I can shorten the filename? I have added the compiler flag -Xmax-classfile-name and set it to 254.
If your /home is an encrypted file system (e.g. LUKS), you might run into this issue.
Setting max-classfile-name to 254 is the default (or it might be 255) - so you're not reducing it much. You should probably be considering something closer to a max length of 70 - 100. You can set it for all your projects by creating ~/.sbt/0.13/local.sbt with the scalac override:
scalacOptions ++= Seq("-Xmax-classfile-name","78")
This is how I solved my problem
mkdir /tmp/myproject-target
cd ~/workspace/myproject
rm -rf target
ln -s /tmp/myproject-target target
I encountered this problem in IntelliJ Ultimate 2016.1.2 (which resembles Intellij 14). I solved it by setting:
-Xmax-classfile-name 78
In File > Settings... > Build, Execution, Deployment > Compiler > Scala Compiler > Additional Compiler Options.
NOTE: there is a space between the option name and its value ("78"), not an equals sign.
Try using a shell script like this:
#!/bin/sh
for file in *; do {
echo -m "$file" | wc -m;
echo "$file"
}
done
Running this in your src/main/scala directory should show you which files have a name with more than 254 chars. I hope this answers your question.
Setting the file length limits might be unsafe, I could not find any official documentation that this solution is safe.
Using un-encrypted directory is not safe.
I want to offer a different approach:
install veracrypt (in ubuntu with apt)
create a non-encrypted directory (outside the encrypted user home dir)
create a veracrypt file container in the new directory
mount the container in
sbt works fine even if the mount point is in the encrypted directory)
It is possible to create the container with a complex password and mount on login
veracrypt -t --pim=0 --protect-hidden=no -k "" -p $PASSWORD $ENCRYPTED_CONTAINER $MOUNT_DIR
We have a Scala project and we use SBT as its build tool.
our CI tool is TeamCity, and we build the project using the command line custom script option with the following command:
call %system.SBT_HOME%\bin\sbt clean package
The build process works fine when the build succeeds, however, when compilation fails - TeamCity thinks that the script exited with exitCode 0 and not 1 as expected, this cause TeamCity build to succeed although the compilation failed.
when we run the same commands on local cmd we see that the errorLevel is 1.
the relevant part of the build log:
[11:33:44][Step 1/3] [error] trait ConfigurationDomain JsonSupport extends CommonFormats {
[11:33:44][Step 1/3] [error] ^
[11:33:44][Step 1/3] [error] one error found
[11:33:45][Step 1/3] [error] (compile:compile) Compilation failed
[11:33:45][Step 1/3] [error] Total time: 12 s, completed Jan 9, 2014 11:33:45 AM
[11:33:45][Step 1/3] Process exited with code 0
how can we make TeamCity recognize the failure of the build?
Try explicitly exit with:
call %system.SBT_HOME%\bin\sbt clean package
echo the exit code is %errorlevel%
exit /b
If you can't get the process to output a non-zero exit code then you could use a build failure condition based on specific text in the build log. See this page for the documentation but in essence you can get the build to fail if it finds the text error found in the build log.
I'm using Sbt for continuous integration (Bamboo). I want to check all the environment variables are set or get a descriptive error message. I use the following approach:
def env(n: String) = Option(System.getenv(n)).getOrElse(throw new RuntimeException("Undefined required environment variable " + n))
val mySetting = env("REQUIRED_ENV_VAR") + "..."
Instead, I get
[error] java.lang.ExceptionInInitializerError
[error] Use 'last' for the full log.
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore? q
Two questions:
How to get full stacktrace without need to use 'last' (simple can't do it on Bamboo)?
How to tell sbt to exit if project loading failed instead of asking for retry etc?
sbt will not enable interactive mode if input stream will be "closed" with (such a hacky) trick:
cat /dev/null | sbt taskname
or if you are not able to use pipes create a shell script like this:
#!/bin/sh
sbt "$#" < /dev/null
In sbt v1.3.9 (and probably earlier) there is the --batch switch.
$ sbt --help
Usage: sbt [options]
...
--batch disable interactive mode
...