[libcxx][PATCH] Fix for CMakelists.txt

Michael van der Westhuizen r1mikey at gmail.com
Tue Apr 2 01:20:49 PDT 2013


Hi,

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.

I don't believe there's any need to overcomplicate what's in this file.

Michael

On 01 Apr 2013, at 9:19 PM, G M <gmisocpp at gmail.com> wrote:

> Do you find that the destination directories are created in more uncommon circumstances that like when dstdir expands to multiple/deeper directories too?
> 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.
>  
> 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
> 
> 
> On Tue, Apr 2, 2013 at 4:59 AM, Michael van der Westhuizen <r1mikey at gmail.com> wrote:
> 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.
> 
> 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.
> 
> Michael
> 
> On 01 Apr 2013, at 11:49 AM, G M <gmisocpp at gmail.com> wrote:
> 
> > It does work as long as the destination directory already exists.
> > But I am thinking it might not work if a file (as opposed to a
> > directory) is being copied and the destination directory doesn't exist,
> > then I am concerned that what might happen is that cmake is going to copy
> > the file and give it the name of the intended directory rather than create
> > that directory and copy the file into it.
> > I'm no cmake expert, so if anyone agrees who is, could they suggest a fix
> > that would prevent that.
> >
> > The include directory does already exist in the use case presented so it
> > works for that,but other sub-directories might not exist and in those
> > circumstances it seems it might fail.
> >
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130402/69803906/attachment.html>


More information about the cfe-commits mailing list