[ovs-dev] Autoconf limits on Windows

Tue Nov 26 10:46:36 UTC 2013

> On 26/nov/2013, at 08:10, "Ben Pfaff" <blp at 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" <blp at 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" <blp at 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" <shettyg at nicira.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>>> On Nov 25, 2013, at 5:05 PM, Jesse Gross <jesse at 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 <blp at 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 <blp at 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 at openvswitch.org
>>>>>>>>>>> http://openvswitch.org/mailman/listinfo/dev
>>>>>>>>> _______________________________________________
>>>>>>>>> dev mailing list
>>>>>>>>> dev at openvswitch.org
>>>>>>>>> http://openvswitch.org/mailman/listinfo/dev
>>>>>>> _______________________________________________
>>>>>>> dev mailing list
>>>>>>> dev at openvswitch.org
>>>>>>> http://openvswitch.org/mailman/listinfo/dev
>>>>>> _______________________________________________
>>>>>> dev mailing list
>>>>>> dev at openvswitch.org
>>>>>> http://openvswitch.org/mailman/listinfo/dev
>> _______________________________________________
>> dev mailing list
>> dev at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev