> On 26/nov/2013, at 08:10, "Ben Pfaff" <b...@nicira.com> wrote: > > Since you're OK with manual updates, I'm happy in principle with having > IDE-related files in the repository as long as they are not unreasonably > large. But there's something weird going on. Why would special files > would be needed for syntax highlighting or Git integration or even > integrated debugging? Other editors and IDEs manage these features > without special files (I often use these features in Emacs). >
Visual Studio unfortunately does not work with Makefiles, nor it's able to import a project from them. It can run a Makefile based project, but that's almost useless. > So: are you really talking about an alternate build system? I really > don't want two build systems around because that will inevitably cause > trouble, e.g. when we add new tests to configure.ac that add new > config.h macros, for example. I also doubt that generating the > testsuite is going to work gracefully. > We can leave the tests in configure.ac. Although Visual Studio provides testing tools that help a lot in debugging issues encountered during testing, we can IMO skip those for the benefits of a single multi platform testing framework. This will also rule out issues with the "alternative" Visual Studio builds. > I guess by "CI gate" you mean something preventing checking into the > repository until basic tests pass? We haven't implemented anything like > that, yet. We expect developers to run "make check" before applying > commits. On a normal dev box (such as the 2-year-old laptop I'm typing > this on) this takes under a minute. It isn't really practical to expect > a dev to do this on multiple OSes, though, so we'd need something more > sophisticated if we were to attempt this for Windows. > Are you familiar by any chance with how Gerrit / Jenkins / SmokeStack work on OpenStack? In a nutshell, the basic idea is that a developer submits a patchset for review with a git extension to Gerrit which in turn executes the unit and integration tests on a temporary git branch with that patchset applied. The result is a +1 / -1 vote. This can be done on multiple platforms (Linux, Windows, etc), by using for example OpenStack to spin up a VM for each run. Peer review takes typically place at this point and if the patch is reviewed positively and approved, another run of unit / integration tests is performed to rule out rebasing issues. If the outcome is positive, the code is merged in the target git branch. Gerrit provides lots of additional advantages including a web site that eases up the review process providing visual patchset diffs, comments on the code lines, etc. >> On Tue, Nov 26, 2013 at 01:55:32AM +0000, Alessandro Pilotti wrote: >> Of course I do. :-) >> >> A CI gate might be very helpful for this purpose as a further step to >> keep those files aligned by avoiding regressions IMO but for the time >> being we'd perfectly fine with manual updates. >> >>> On 26/nov/2013, at 03:19, "Ben Pfaff" <b...@nicira.com> wrote: >>> >>> You realize that no one else is going to update them, right? >>> >>>> On Tue, Nov 26, 2013 at 12:03:02AM +0000, Alessandro Pilotti wrote: >>>> What if we simply add a folder with the Visual Studio build files to begin >>>> with? >>>> >>>>> On 26/nov/2013, at 01:29, "Ben Pfaff" <b...@nicira.com> wrote: >>>>> >>>>> We're not switching to CMake. If you have something to generate the >>>>> XML files you need, we'll check that in. >>>>> >>>>>> On Mon, Nov 25, 2013 at 11:23:37PM +0000, Alessandro Pilotti wrote: >>>>>> Visual Studio is the "de facto" IDE for Windows development. It provides >>>>>> all the features you'd expect from a modern environment (integrated >>>>>> debugger, refactoring tools, Git integration, syntax highlighting and a >>>>>> gazillion additional features) and in general it allows to be a few >>>>>> orders of magnitude more productive than a text editor and some command >>>>>> line tools. >>>>>> >>>>>> For other scenarios, e.g. Python or other interpreted dynamic languages, >>>>>> I'm personally a great fan of simpler editors like Sublime, but I'd >>>>>> never even think of working in C/C++/C#/Java/etc without an IDE and >>>>>> especially an integrated debugger. >>>>>> >>>>>> I can assure you that no Windows developer I ever met would ever accept >>>>>> to jump back in time 20 years and use vi as her/his main productivity >>>>>> tool. :-) If this port is meant to attract more Windows community >>>>>> contributors then Visual Studio support is substantially mandatory. >>>>>> >>>>>> Said that, if in your intentions the project is not meant to be >>>>>> developed on Windows but only compiled to produce the binaries, well, >>>>>> makefiles are enough. >>>>>> >>>>>> I suggest to take a tour of other well known cross platform projects and >>>>>> see how those manage the Windows builds. You'll see that some of them >>>>>> consider Windows as a platform for builds only (basically no >>>>>> development), some use CMake to support all the required platforms (Qt5, >>>>>> MySQL, FreeRDP come to mind) and some use separate build systems >>>>>> (CPython, Apache, just to name a couple). >>>>>> >>>>>> If you're interested we can record a quick webcast to show how to use >>>>>> Visual Studio for Open vSwitch development activities. This might help >>>>>> in clarifying some of the statements above. >>>>>> >>>>>> As a final note, Visual Studio files are just XML files, so generating >>>>>> them dynamically is not that complicated if we really have to. >>>>>> >>>>>> Alessandro >>>>>> >>>>>>> On 26/nov/2013, at 00:18, "Gurucharan Shetty" <shet...@nicira.com> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Nov 25, 2013, at 5:05 PM, Jesse Gross <je...@nicira.com> wrote: >>>>>>>> >>>>>>>> They're the equivalent of makefiles for Visual Studio. Without them >>>>>>>> you can't use the Windows-native development tools so while it's not >>>>>>>> impossible to work it certainly makes life more difficult. >>>>>>> >>>>>>> One can still edit the files using a vi editor (or any other simple >>>>>>> editor)on windows and do a make. Probably the disadvantage is that you >>>>>>> can't use visual studio ide to write code(?). >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> On Mon, Nov 25, 2013 at 1:53 PM, Ben Pfaff <b...@nicira.com> wrote: >>>>>>>>> What I'm trying to get at is, what are the "solution and related >>>>>>>>> projects" good for? The non-Windows world does fine without them, so >>>>>>>>> if "make" can work on Windows then why is the result "basically >>>>>>>>> useless for any practical development purpose"? >>>>>>>>> >>>>>>>>>> On Mon, Nov 25, 2013 at 04:50:40PM -0500, Ethan Jackson wrote: >>>>>>>>>> My understanding is that Guru is working on a solution to this >>>>>>>>>> problem. What were your thoughts? >>>>>>>>>> >>>>>>>>>> Ethan >>>>>>>>>> >>>>>>>>>>>> On Mon, Nov 25, 2013 at 3:52 PM, Ben Pfaff <b...@nicira.com> wrote: >>>>>>>>>>>> On Mon, Nov 25, 2013 at 08:11:00PM +0000, Alessandro Pilotti wrote: >>>>>>>>>>>> We did some testing with autoconf / automake on Windows. Makefiles >>>>>>>>>>>> are getting generated correctly although we cannot obviously verify >>>>>>>>>>>> the result with a full build since we didn?t port all the patches >>>>>>>>>>>> to >>>>>>>>>>>> the master branch yet. >>>>>>>>>>>> >>>>>>>>>>>> There?s anyway a huge limitation: it does not generate a Visual >>>>>>>>>>>> Studio solution and related projects, which means that it?s >>>>>>>>>>>> basically useless for any practical development purpose. >>>>>>>>>>> >>>>>>>>>>> What are those files good for? >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dev mailing list >>>>>>>>>>> dev@openvswitch.org >>>>>>>>>>> http://openvswitch.org/mailman/listinfo/dev >>>>>>>>> _______________________________________________ >>>>>>>>> dev mailing list >>>>>>>>> dev@openvswitch.org >>>>>>>>> http://openvswitch.org/mailman/listinfo/dev >>>>>>> _______________________________________________ >>>>>>> dev mailing list >>>>>>> dev@openvswitch.org >>>>>>> http://openvswitch.org/mailman/listinfo/dev >>>>>> _______________________________________________ >>>>>> dev mailing list >>>>>> dev@openvswitch.org >>>>>> http://openvswitch.org/mailman/listinfo/dev >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
