[PATCH] Fix Windows build

[Robinson, Paul]

r223425.  Thanks for catching the missing braces…
--paulr

From: Jordan Rose [mailto:jordan_rose at apple.com]
Sent: Thursday, December 04, 2014 4:30 PM
To: Robinson, Paul
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] Fix Windows build

Cool, thanks. One comment still:

+    if (Project_WC_REVISION)
+      set(revision ${Project_WC_REVISION} PARENT_SCOPE)
+    endif()
+    if (Project_WC_URL)
+      set(repository ${Project_WC_URL} PARENT_SCOPE)
+    endif()

These should be using "${revision}" and "${repository}" instead of "revision" and "repository". It happens to work in this case because the variable names you picked are the same as the variables in the caller, but we should get it right anyway! (The macro arguments are really "revision_var" and "repository_var" or something.)

After fixing that, please feel free to commit!

I am more than happy to let you deal with the non-svn-git-branch-inside-git-svn-clone problem!  But it's probably easy to handle by having get_source_info fall back to the git path if git-svn produces no result.

Something like this. There are cases where git-svn takes a very long time to produce no result, though. We'll see...!

Jordan


On Dec 4, 2014, at 16:15, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:

Hi Jordan,
Sorry for the delay, here's a revised patch.
-        git-svn path uses a single 'git svn info' to extract info; this also lets me  steal regexes from FindSubversion.cmake so it really should work exactly like the SVN case.
-        git path doesn't assume the name of the remote. That regex might be more paranoid than it needs to be, but it works.
I've now tried this with git, git-svn, and svn.

I am more than happy to let you deal with the non-svn-git-branch-inside-git-svn-clone problem!  But it's probably easy to handle by having get_source_info fall back to the git path if git-svn produces no result.
Thanks,
--paulr

From: Jordan Rose [mailto:jordan_rose at apple.com]
Sent: Monday, December 01, 2014 7:21 PM
To: Robinson, Paul
Cc: Sean Silva; llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>; Mark Lacey
Subject: Re: [PATCH] Fix Windows build

Oh right, the Makefile build still exists. :-)

On Dec 1, 2014, at 14:12 , Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:

Hi Jordan,
GetSourceVersion and GetRepositoryPath are still used by clang/lib/Basic/Makefile, so we should not delete them.  Your original thought--have make and CMake use the same scripts—was laudable, but we'd have to do something like rewrite this stuff in Python to make it both multi-platform and multi-build-tools compatible.  I don't have the Python chops for that, but if somebody else wants to do it, I'm happy to throw away my stuff.

So, I used separate git-svn commands because I was first adapting code from VersionFromVCS.cmake (which uses git svn log) and then translating GetRepositoryPath into CMake (which uses git svn info) and finally filling in the holes regarding getting both bits of info for the 3 source-control options.
But of course 'git svn info' has both the URL and the revision, so rejiggering the regex stuff to extract it all from one git command would be preferable.

How does the pure git case "regress" from what GetRepositoryPath does?  GetRepositoryPath looks for the "git remote –v" line with "fetch" in it, then prints the URL from that line.  I thought my CMake code would do the same.  Or should I not be looking for the text "origin"?  I was seeing that in my git repo, but I'm not exactly a sophisticated git user.  Maybe I should have that match any non-whitespace string?

I just saw this:

+    # FIXME: Extract URL from 'git remote -v'

But maybe I was looking at the wrong version of the patch. Regardless, I would do the same thing GetRepositoryPath does, which doesn't assume the name of the remote.

On a related note, Mark mentioned an issue using the git-svn code path when the current git branch isn't based on SVN, but I'll look into that later—no need to block this patch on it.

Thanks, Paul,
Jordan

<GetSVN3.diff>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141205/0c02aaa7/attachment.html>