[ofw] RE: porting IB management code to Windows

[Smith, Stan]

Hefty, Sean wrote:
>> Hold the presses - there is an absolute requirement that any part of
>> a WinOF release builds using the WDK build environment!
>
> Why is this an absolute requirement for userspace applications?
>
> ND is provided as a binary component that is built using some unknown
> build environment.  The source code is not available.  It has a
> different license. But it still ships with WinOF.  Building in the
> WDK is a political decision, not a technical one.

ND is built in the WDK environment by those who have MS src license.

Political decision? Maybe so, but nonetheless WDK it is until such a time that the Windows community agrees it is not.
The bottom-line fact of the OpenIB/WinOF svn tree has been that upon svn checkout/update the src tree is buildable without further additions other than the WDK build environment.

The Windows svn tree is built and tested by at least 4 different companies, some daily.
There needs to be a consensus before major changes to the Windows build process are installed.

BTW, I am in favor of common IB management src.

So if 'everyone' is in favor of having a common src base, what's so hard about having a few #ifdef __WIN32?
Yes it's not the optimal approach, although changing compilers, building elsewhere, adding binaries are all certainly more offensive IMHO.

BTW, since the 'common src' will he maintained in the Linux world - who is to say patches will consider Windows ramifications and be tested in the Windows environment anyway?
History has not demonstrated this type of development diligence, hence the code fork which brings us to today's situation.

Make the process easy one everyone and one day into the future, maybe MS will wakeup and the WDK will be c99 compliant?

Stan.

>
> At the extremes, the IB management maintainers can refuse to support
> Windows because they don't like the changes to build using the MS WDK
> compiler.  Or, WinOF can refuse to ship IB management utilities
> because it builds differently. Obviously no one benefits from taking
> these extreme stances.
>
> There are real benefits to maintaining a single source code base.  I
> would guess between 10-25 patches are added to the management tree
> each week, many, if not most, by developers that only care about
> Linux.  The Windows stack gains a lot by being able to take advantage
> of those changes.  (Note that most patches are against opensm.  If we
> limit the current discussion to only the diags and libibmad, we're
> looking at roughly 12,000 lines of code and probably about 5 patches
> per week.)
>
> I posted a patch to show the changes necessary to build in the WDK
> environment. Jason asked, "Is there any way it would be acceptable to
> use gcc (or even the Intel compiler) as the mandatory Windows C
> compiler?"  And Sasha's commented, "I would prefer to minimize amount
> of needed changes and would really prefer to not get a lot of
> limitations in using modern C."  My reply was "I personally have no
> issue with using a different compiler, but the WWG would need to
> decide on that sort of change."
>
> I looked into the issue.  The compiler that ships with the WDK does
> not support c99 to the extent needed.  Because using the Intel
> compiler was convenient for me, I tested with that and was eventually
> able to reduce the necessary code changes.  I built in the WDK build
> environment.
>
> At this point, I see the following options:
>
> 1. Fork the code:
> The benefits or requirement of building within the existing Windows
> build environment is greater or more important than maintaining a
> single source code base.
> 2. Accept the changes as posted:
> If the benefits or requirement of building within the existing
> Windows build environment is greater or more important than allowing
> c99 constructs, but not at the cost of forking the code.
> 3. Build the IB management with a different compiler:
> The benefits of support c99 is greater than the benefits of building
> within the existing Windows build environment.
>
> If there's another solution here, I'm open to ideas.  Of these three,
> I prefer option 2 or 3.  Option 3 means slightly more work for me
> because it requires making binaries available, but there are real
> benefits to supporting c99.
>
> - Sean