Just to be clear, I am not advocating having to deal with the perforce SCC integration dialog for every project in the solution. In our set up, we need to deal with it once for the solution... without having access to AuxPath. However, I do imagine, that it probably has something to do with where the local path ends up pointing to and whether your solution pulls projects from different P4 work-spaces, though I have never done that myself personally.
I suggested making AuxPath optional because the binding will work without that property, and it will work efficiently if carefully crafted. I can not say that a binding will succeed if any of the other properties are omitted, though perhaps they might with some SCC providers... I didn't write the original binding logic, I don't use other providers, and I certainly have never seen any documentation on the Visual Studio SCC interface... I've heard you need to sign an NDA with Microsoft for that or something. As far as there being logic to using a relative path as opposed to an absolute one, no... I can't say that I know what it is if there is any. Again, I don't fully understand how SCC integration works. I can only say that I have tried relative paths, and they work better for me than the report you provided originally. Also, if I set up the bindings after solution generation from within visual studio 2010, that is what the IDE and/or perforce puts there. Steven On Tue, Nov 1, 2011 at 7:40 AM, Robert Dailey <rcdai...@gmail.com> wrote: > On Mon, Oct 31, 2011 at 11:59 PM, Steven Velez <sbv1...@gmail.com> wrote: >> >> Hi Robert, >> >> I reviewed the patch, and I am not sure vsAuxPath should be a >> requirement. As I stated earlier, we've gotten the binding to work >> acceptably without it and I assume others have as well. Further, some >> users may prefer to enter their connection information in to the >> perforce dialog on first invocation instead of having to configure the >> cmake cache to setup their bindings. > > I never said it wouldn't work without AuxPath, I am just stating that it > works better with it. AuxPath is where the connection string is placed. > Each person that uses CMake is different and I see no reason why AuxPath > should not be an available option to the user, especially since I've already > done the work of adding it in. > If users want to continuously press "OK" on the perforce connection dialog > for every project opened in the solution, that's fine by me but I certainly > don't want to deal with that annoying behavior. > >> >> To be clear, I have no objections to adding AuxPath support (not that >> my objections count for anything around here). Its that just as it >> stands now, if you don't supply it, you won't get any bindings. > > I can easily make it optional. I was just following the design already in > place, which forces all parameters to be required. > >> >> Also, you may have better results getting your patch integrated by >> opening a defect in cmake's bug tracker and attaching the patch to >> that. The preferred patch generation method is also described here: >> http://www.mail-archive.com/cmake@cmake.org/msg36619.html > > Thanks for the info!! > >> >> By the way, as I stated in an earlier mail, if you wish to pursue this >> further, if you change "C:/Code/work/sandbox" to "..\..\.." where that >> path points to "C:\Code\work\sandbox" relative to the target being >> bound, you should have better results. > > I read your last email but I fail to see the logic behind why a relative > path works better than an absolute one. Based on my tests, using an absolute > path has not resulted in any prompts to save the solution/projects. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
