[ https://issues.jenkins-ci.org/browse/JENKINS-14064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163811#comment-163811 ]
Yury Zaytsev commented on JENKINS-14064: ---------------------------------------- Hi, {quote} A simple workaround would be to pipe the output through a script that replaces the "../../sli" references with "sli". {quote} Yes, this could work, for example, in the plugin you can make a field to enter regexps to apply to the file names, i.e. s/\.\.\/(.*)$/\1/, but this solution kind of sucks. {quote} Do you have an idea on how to resolve that directly in the plug-in? {quote} I think your idea of trying to find whether files are in the workspace by looking for them was a very good and generic one. Only maybe make the logic a bit smarter (I didn't have a look at the source code yet, to figure how you are doing it at the moment)... but what I can't understand is why it works in some cases, and in some cases not??? The file names are unique (see example above). Also, now I can confirm that it's the same problem for gcc: https://qa.nest-initiative.org/job/nest-matrix-10kproject/3/warnings12Result/? . > Copying the source file on the Hudson master failed / Clang / autotools VPATH > ----------------------------------------------------------------------------- > > Key: JENKINS-14064 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14064 > Project: Jenkins > Issue Type: Bug > Components: warnings > Environment: Master: RHEL 6.2, Jenkins LTS, Warnings 4.5; Slave: > Fedora Core 16 > Reporter: Yury Zaytsev > Assignee: Ulli Hafner > Priority: Minor > Attachments: consoleText.log.zip > > > Hi, > I set up a VPATH build of an autotools-based software in a custom workspace > (set per node) in "build" directory: > /mnt/ram/workspace/[job-id]/build > Therefore generally files are referenced in the log as ../../folder/file.cpp, > because the build directory only contains Makefiles and other temporarily > generated data. E.g. when files from nestkernel are compiled through the > Makefiles in > /mnt/ram/workspace/[job-id]/build/nestkernel > the source files are referenced as ../../nestkernel/file.cpp so that it > resolves as > /mnt/ram/workspace/[job-id]/nestkernel/file.cpp > I'm afraid this can't be possibly changed. Now because of that LLVM parser > extracts warnings as belonging e.g. to "../../nestkernel", so apparently the > file references are later resolved as > /mnt/nestkernel/file.cpp > relative to > /mnt/ram/workspace/[job-id]/ > and not to > /mnt/ram/workspace/[job-id]/build/nestkernel > which of course doesn't exist so I'm getting the following kind of errors > when I try to see the file: > {code} > Content of file connection_manager.cpp > 01 Copying the source file '../../nestkernel/connection_manager.cpp' from the > workspace to the build folder > '/var/lib/jenkins/jobs/nest-clang-test/builds/2012-06-08_17-46-33/workspace-files/7976711b.tmp' > on the Hudson master failed. > 02 Seems that the path is relative, however an absolute path is required when > copying the sources.%nIs the file 'connection_manager.cpp' contained more > than once in your workspace? > 03 Is the file '../../nestkernel/connection_manager.cpp' a valid filename? > 04 If you are building on a slave: please check if the file is accessible > under '$HUDSON_HOME/[job-name]/../../nestkernel/connection_manager.cpp' > 05 If you are building on the master: please check if the file is accessible > under > '$HUDSON_HOME/[job-name]/workspace/../../nestkernel/connection_manager.cpp' > 06 hudson.util.IOException2: remote file operation failed: > ../../nestkernel/connection_manager.cpp at > hudson.remoting.Channel@68b7cdc6:fc-16-i386-2 > 07 at hudson.FilePath.act(FilePath.java:780) > 08 at hudson.FilePath.act(FilePath.java:766) > 09 at hudson.FilePath.copyTo(FilePath.java:1460) > 10 at > hudson.plugins.analysis.core.HealthAwarePublisher.copyFilesWithAnnotationsToBuildFolder(HealthAwarePublisher.java:398) > 11 at > hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:355) > 12 at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:27) > 13 at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:697) > 14 at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:672) > 15 at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:650) > 16 at hudson.model.Build$RunnerImpl.post2(Build.java:162) > 17 at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:619) > 18 at hudson.model.Run.run(Run.java:1429) > 19 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > 20 at hudson.model.ResourceController.execute(ResourceController.java:88) > 21 at hudson.model.Executor.run(Executor.java:238) > 22 Caused by: java.io.FileNotFoundException: > ../../nestkernel/connection_manager.cpp (No such file or directory) > 23 at java.io.FileInputStream.open(Native Method) > 24 at java.io.FileInputStream.<init>(FileInputStream.java:137) > 25 at hudson.FilePath$31.invoke(FilePath.java:1465) > 26 at hudson.FilePath$31.invoke(FilePath.java:1460) > 27 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2045) > 28 at hudson.remoting.UserRequest.perform(UserRequest.java:118) > 29 at hudson.remoting.UserRequest.perform(UserRequest.java:48) > 30 at hudson.remoting.Request$2.run(Request.java:287) > 31 at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > 32 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > 33 at java.util.concurrent.FutureTask.run(FutureTask.java:166) > 34 at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > 35 at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > 36 at java.lang.Thread.run(Thread.java:679) > {code} > A typical log snippet looks like this: > {code} > mv -f .deps/libdevelopermodule_la-maturing_connector_fr.Tpo > .deps/libdevelopermodule_la-maturing_connector_fr.Plo > /bin/sh ../libtool --tag=CXX --mode=compile clang++ -DHAVE_CONFIG_H -I. > -I../../developer -I../libnestutil -I../../libnestutil -I../../librandom > -I../../sli -I../../nestkernel -I../../models -I../../libltdl -I/usr/include > -W -Wall -pedantic -Wno-long-long -O2 -MT > libdevelopermodule_la-stdp_triplet_connection.lo -MD -MP -MF > .deps/libdevelopermodule_la-stdp_triplet_connection.Tpo -c -o > libdevelopermodule_la-stdp_triplet_connection.lo `test -f > 'stdp_triplet_connection.cpp' || echo > '../../developer/'`stdp_triplet_connection.cpp > libtool: compile: clang++ -DHAVE_CONFIG_H -I. -I../../developer > -I../libnestutil -I../../libnestutil -I../../librandom -I../../sli > -I../../nestkernel -I../../models -I../../libltdl -I/usr/include -W -Wall > -pedantic -Wno-long-long -O2 -MT > libdevelopermodule_la-stdp_triplet_connection.lo -MD -MP -MF > .deps/libdevelopermodule_la-stdp_triplet_connection.Tpo -c > ../../developer/stdp_triplet_connection.cpp -fPIC -DPIC -o > .libs/libdevelopermodule_la-stdp_triplet_connection.o > In file included from ../../developer/stdp_triplet_connection.cpp:19: > In file included from ../../nestkernel/network.h:24: > In file included from ../../nestkernel/model.h:23: > In file included from ../../nestkernel/node.h:28: > In file included from ../../sli/dictdatum.h:22: > In file included from ../../sli/interpret.h:28: > In file included from ../../sli/tokenstack.h:25: > ../../sli/tokenarray.h:422:19: warning: operands of ? are integers of > different signs: 'unsigned long' and 'long' [-Wsign-compare] > rot = (rot < 0) ? rot+size() : rot; > ^ ~~~~~~~~~~ ~~~ > {code} > Apparently this problem is not specific to Clang, but probably is also valid > for GCC (but I don't seem to remember anything like that, can it be that > workspace scan is not working for LLVM?!), so as long as VPATH (out of source > tree) builds are involved this problem manifests itself. > Is there any way in which this can be disambiguated? > Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira