[
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
