[CMake] SCC bindings missing AUXPATH support?

[Steven Velez]

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 <rcdailey at gmail.com> wrote:
> On Mon, Oct 31, 2011 at 11:59 PM, Steven Velez <sbv1976 at 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.