Bug 91436 – NRWRT Should provide a VS project to work on

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Don Olmstead]

NRWRT Should provide a VS project to work on

[Don Olmstead]

Created attachment 152628 [details]
Patch

[Don Olmstead]

Created attachment 152636 [details]
Proposed patch

[Don Olmstead]

Created attachment 152637 [details]
Patch

[Don Olmstead]

Created attachment 152648 [details]
Patch

[Dirk Pranke]

Comment on attachment 152648 [details]
Patch

looks fine. 

in the future, don't forget to set r? if you want the patch to be reviewed, and cq? if you want it to be landed for you.

[Adam Barth]

How do we keep this file up-to-date / how will we know when we break it?

[WebKit Review Bot]

Comment on attachment 152648 [details]
Patch

Clearing flags on attachment: 152648

Committed r122789: <http://trac.webkit.org/changeset/122789>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Dirk Pranke]

(In reply to comment #6)
> How do we keep this file up-to-date / how will we know when we break it?

Fair questions. My general thinking was that this is being provided as a utility for people who might want to mess around with debugging python from inside visual studio, and there are no expectations that people who aren't using this will keep it up to date or need to worry about breaking it.

[Tony Chang]

It's also weird that this file is VS2010, but all the other sln files in the tree are VS2005.

I'm not sure there's much benefit to checking this into the tree since it's likely going to bitrot in a few days.

[Dirk Pranke]

(In reply to comment #10)
> It's also weird that this file is VS2010, but all the other sln files in the tree are VS2005.
> 

You can't use other toolchains before 2010, so 2005/2008 wouldn't work.

> I'm not sure there's much benefit to checking this into the tree since it's likely going to bitrot in a few days.

We don't move or add files around that often, and updating it is not hard.

It's not obvious to me that there's a better way to get a project for the python files, but I'm open to suggestions?

[Adam Barth]

> It's not obvious to me that there's a better way to get a project for the python files, but I'm open to suggestions?

I just use sublime, which generates the project from the file system.  There isn't anything to a python "project" except the file system.

[Dirk Pranke]

(In reply to comment #12)
> > It's not obvious to me that there's a better way to get a project for the python files, but I'm open to suggestions?
> 
> I just use sublime, which generates the project from the file system.  There isn't anything to a python "project" except the file system.

Using pytools in visual studio you get debugger integration. Plus I should've been clearer that I meant "VS project" :).

[Dirk Pranke]

whoops, hit return too soon ... obviously we don't want to check in project-type files for every editor that people might want to use, but this still seems to add enough value to me to be worth it. I'm open to other suggestions, though.

[Tony Chang]

I think it's fine for Don to just keep these files local.

It's kind of like people who want to use eclipse for WebKit development.  It's allowed (I think raf does it from time to time so he can use the debugger UI), but since it's not part of the official work flow, we don't check in eclipse files.

Also, .sln and .vcproj files normally go in directories that match the name of the vcproj file. E.g., Tools/Scripts/webkitpy/webkitpy.pyproj/webkitpy.pyproj and Tools/Scripts/webkitpy/webkitpy.pyproj/webkitpy.sln would probably be more consistent with the existing directory structure.

[Dirk Pranke]

The advantage of don checking them in is that I get to use them, too :).

It's too bad we don't have an "experimental" / misc directory or some other mechanism for sharing non-critical files.

[Eric Seidel (no email)]

I think this is a really bad idea and should be removed.

[Eric Seidel (no email)]

I view this as an unnecessary maintenance burden. :)  There isn't anything to webkitpy besides the files on disk, I don't see why having a second file-list which requires maintenance is a good idea.

[Eric Seidel (no email)]

As Adam notes, Sublime has been an excellent tool for those of us writing webkitpy (and does not require project files):
http://www.sublimetext.com/2

It also works on Windows.

[Eric Seidel (no email)]

Re-opened since this is blocked by bug 106036

[Eric Seidel (no email)]

I don't mean to be mean... but I do think this was a bad idea, and I'm surprised I wasn't CC'd.

I've posted a patch to remove them:
https://bugs.webkit.org/show_bug.cgi?id=106036

I appreciate your interest in contributing to NRWT and webkitpy, but I'm not interested in maintaining visual studio project files.

If you'd like to create a script to create these files for you (and others who would like to use them) that seems totally reasonable.  Then you don't have to check anything in.

[Eric Seidel (no email)]

(by "not check anything in" above, I meant "not have to check project files in")  The project files you checked in could be trivially generated from a script anyway. :)

[Brent Fulgham]

Closing bug as these files have been removed by 106036.