<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>While I agree that in the general case you'd want a more general solution this is not a general use case. This is a very specific case, where only libsupc++ builds have a single subdirectory (bits). The copy lists are on lines 133, 141 and 145. We do not simply copy the the contents of a directory or pattern, but we copy very specific files.</div><div><br></div><div>I don't believe there's any need to overcomplicate what's in this file.</div><div><br></div><div>Michael</div><div><br><div><div>On 01 Apr 2013, at 9:19 PM, G M <<a href="mailto:gmisocpp@gmail.com">gmisocpp@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>Do you find that the destination directories are created in more uncommon circumstances that like when dstdir expands to multiple/deeper directories too?</div><div>It seems the best solution (ideally) would be that there be a flag on cmake so that it can say explicitly that this is a copy operation to a file in a possibly non-existent directory so that it can create the directory, and ensure that it is not interpreted as a copy of a file with an implicit rename to another filename, which is what happens if the destination directory did not exist. we can't just using a trailing slash as normal to signify this as for the problem case it would result in // when dstdir is empty as it can be in this case.</div>
<div> </div><div>altneratively the script could be fixed in another way in cmake, but this is what I perceived to be a possible problem even if the patch does fix things for the particular case</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Apr 2, 2013 at 4:59 AM, Michael van der Westhuizen <span dir="ltr"><<a href="mailto:r1mikey@gmail.com" target="_blank">r1mikey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The destination directory always exists. See CMakeLists.txt, line 94 (in the setup_abi_lib macro), where each ABI library directory is created at the time CMake is run.<br>
<br>
This patch looks good to me, although it's not necessary for the version of CMake I run (2.8.10.1). I've tested it against all three ABI libraries on Linux with no regression.<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 01 Apr 2013, at 11:49 AM, G M <<a href="mailto:gmisocpp@gmail.com">gmisocpp@gmail.com</a>> wrote:<br>
<br>
> It does work as long as the destination directory already exists.<br>
> But I am thinking it might not work if a file (as opposed to a<br>
> directory) is being copied and the destination directory doesn't exist,<br>
> then I am concerned that what might happen is that cmake is going to copy<br>
> the file and give it the name of the intended directory rather than create<br>
> that directory and copy the file into it.<br>
> I'm no cmake expert, so if anyone agrees who is, could they suggest a fix<br>
> that would prevent that.<br>
><br>
> The include directory does already exist in the use case presented so it<br>
> works for that,but other sub-directories might not exist and in those<br>
> circumstances it seems it might fail.<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></body></html>