Support #315
cmake-based recipe with subdir fails to move subdir if contained folder exists on top level
| Status: | Resolved | Start date: | 2014-10-29 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: |  Jan Moringen | % Done: | 100% | |
| Category: | build-generator | Spent time: | 3.90 hours | |
| Target version: | Toolkit 0.1 |
Description
If you have a look at the YARP-bindings folder structure:
https://github.com/robotology/yarp
The bindings folder is located in $YARP_ROOT/bindings. If you add a "sub-directory" variable to your recipe, which is needed in this case, the analysis works well. However, the according Jenkins job is then comprised of two build steps:
1.
mv $(find "bindings" -maxdepth 1 -mindepth 1) .
2.
cmake config, compile & install ...
1. will already fail because the folder "bindings" contains a folder called "src" which also exists in $YARP_ROOT folder (c.f. github)
I am not so sure if this is a corner case or not --- however I guess we need to address this.
subdir-test.sh 
(537 Bytes)
History
#1
Updated by Florian Lier about 10 years ago
- Description updated (diff)
#2
Updated by Florian Lier about 10 years ago
- Description updated (diff)
#4
Updated by Jan Moringen about 10 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Should be fixed in master and 0.3 branches of the generator.
#5
Updated by Florian Lier about 10 years ago
It seems that at least in the current *.tar.gz (which gets deployed after each successful build on cor.ci) the issue is not fixed:
[flier@silver]-[/homes/flier/Projects/Ongoing/CITK/build-gen/jenkins] [10:52]$ ./job-configurator --version build-generator version 0.3.36
mv $(find "bindings" -maxdepth 1 -mindepth 1) .
#6
Updated by Florian Lier about 10 years ago
Stop! There is something from with my jenkins installation ;) Sorry. Will update this topic soon!
#7
Updated by Florian Lier about 10 years ago
Okay, thanks Jan. Fix is confirmed!
find . -mindepth 1 -maxdepth 1 -not -name "bindings" -exec rm -rf {} \; # Uniquely rename directory. temp=$(mktemp -d ./XXXXXXXX) mv "bindings" "${temp}/" # Move contents to toplevel workspace directory. find "${temp}" -mindepth 2 -maxdepth 2 -exec mv {} . \; rm -r "${temp}"
#8
Updated by Simon Schulz almost 10 years ago
- Status changed from Resolved to Feedback
- % Done changed from 100 to 80
this seems to be still broken if the subdir is something like "client/cpp"
(see flobidev-core-client_cpp.project)
#9
Updated by Simon Schulz almost 10 years ago
fix: please use
$num_of_slashes_in_name=1
find . -mindepth 1 -maxdepth (1+ $num_of_slashes_in_name) -not -samefile "client/cpp"
#10
Updated by Simon Schulz almost 10 years ago
the last thing did not work properly,
this is working:
- Uniquely rename directory.
temp=$(mktemp -d /tmp/XXXXXXXX)
mv client/cpp/* "${temp}/"
rm -rf *
- Move contents to toplevel workspace directory.
mv ${temp}/* .
rm -r "${temp}"
#11
Updated by Florian Lier almost 10 years ago
I can confirm this. This only happens if the subdir is "two" levels, i.e, "client/cpp". For one subfolder like "client" the current implementation works.
[flier@dev]-[/home/flier/Projects/Ongoing/citk/jenkins] [14:51]$ ./job-configurator --version build-generator version 0.3.37
#12
Updated by Florian Lier almost 10 years ago
Proposal for search command:
find . -type d | grep -v client/cpp
#13
Updated by Jan Moringen almost 10 years ago
Simon Schulz wrote:
this is working:
> # Uniquely rename directory. > temp=$(mktemp -d /tmp/XXXXXXXX) > mv client/cpp/* "${temp}/" > > rm -rf * > > # Move contents to toplevel workspace directory. > mv ${temp}/* . > rm -r "${temp}" >
I think Jenkins jobs should not modify files outside their respective workspace. Also, I think mv … /tmp/ would fail if /tmp/ was on a different filesystem.
#14
Updated by Simon Schulz almost 10 years ago
Why should that fail?
You are right, it would be nice to stay in the prefix with all the stuff. But that one works for me.
The strange thing is the build generator generated code also fails for single level directories as well... This was working some time ago
#15
Updated by Jan Moringen almost 10 years ago
Simon Schulz wrote:
Why should that fail?
It wouldn't. I confused mv(1) and rename(2).
The strange thing is the build generator generated code also fails for single level directories as well... This was working some time ago
There was some problem with sub-directory values ending with or without "/". Do you use the most recent 0.3 version?
#17
Updated by Florian Lier almost 10 years ago
- Status changed from Feedback to Resolved
- % Done changed from 80 to 100
Thanks Jan!
Is fixed in build-gen 0.3.38