Support #315

cmake-based recipe with subdir fails to move subdir if contained folder exists on top level

Added by Florian Lier about 10 years ago. Updated about 10 years ago.

Status:ResolvedStart date:2014-10-29
Priority:HighDue date:
Assignee:Jan Moringen% Done:

100%

Category:build-generatorSpent 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 Magnifier (537 Bytes) Florian Lier, 2014-11-26 10:02

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 about 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 about 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 about 10 years ago

the last thing did not work properly,
this is working:

  1. Uniquely rename directory.
    temp=$(mktemp -d /tmp/XXXXXXXX)
    mv client/cpp/* "${temp}/"

rm -rf *

  1. Move contents to toplevel workspace directory.
    mv ${temp}/* .
    rm -r "${temp}"

#11 Updated by Florian Lier about 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 about 10 years ago

Proposal for search command:


find . -type d | grep -v client/cpp

#13 Updated by Jan Moringen about 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 about 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 about 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?

#16 Updated by Florian Lier about 10 years ago

Proposal #2

#17 Updated by Florian Lier about 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

Also available in: Atom PDF