On 09/15/2014 10:51 PM, Scott Duplichan wrote: > Jordan Justen [mailto:[email protected]] wrote: > > > ]On Mon, Sep 15, 2014 at 5:38 PM, Scott Duplichan <[email protected]> wrote: > ]> Jordan Justen [mailto:[email protected]] wrote: > ]> > ]> ]I think in most cases our EDK II code base could compile cleanly with > ]> ]these toolchains if minor changes were made to the source. For > ]> ]example, I sent a patch in February: > ]> ]"OvmfPkg: Fix VS2005 compiler warnings" > ]> ]and, you actually commented on the thread. > ]> ] > ]> ]Anyway, I don't work in windows too often, and I ended up not > ]> ]finishing cleaning up that patch and getting it upstream. > ]> ] > ]> ]But, generally, I think this is the approach that we prefer to dealing > ]> ]with compiler warnings. Can we clean up warnings in these packages > ]> ]through code rework instead of disabling warnings? > ]> > ]> From my point of view there are a couple of disadvantages to this approach. > ]> The patch I submitted is a permanent fix. The code rework method requires > ]> on-going work. That is, even if code changes can make the build pass today, > ]> future code rework will be required as the project evolves. That is because > ]> few developers use the old Microsoft tools. They will submit code that > builds > ]> cleanly with newer tools. But eventually someone will build with the old > ]> tools and encounter one of these problems. That will require new code > rework. > ]> A more fundamental objection to me is the idea of changing working, > portable, > ]> bug-free code to work around the 'broken warnings' of old build tools. If > ]> newer build tools didn't exist, then working around these warning > limitations > ]> might make sense. But newer build tools do exist, and in fact most > developers > ]> use them. I won't object further if someone else wants to change the code > ]> for this reason, but I don't want my name on such a change. > ] > ]This would be a major change to how EDK II addresses these kinds of issues. > ] > ]EDK II (and EDK before that) has always pushed for a high number of > ]warnings and caused a build errors on warnings. > ] > ]This strategy goes way back. I don't even know when it started. Maybe > ]Vincent or Andrew know. > ] > ]At any rate, it does indeed cause an ongoing drag, but changing this > ]has never been seriously considered. Maybe this is as much due to > ]momentum as anything. :) > ] > ]But, I don't think you've made the case that disabling these warnings > ]will end up producing better code. (Personally, I couldn't say one way > ]or the other.) > > Hello Jordan, > > The problem this patch set addresses is broken x86 builds using Windows > tool chains. To say 5 of the 9 supported Windows tool chains are broken > is not something to be proud of: > > DDK3790 broken > VS2003 broken > VS2005 broken > VS2008 working > VS2010 working > VS2012 working > VS2013 broken > Cygwin broken (I have been told) > Intel ? > > The patch set is intended to make currently broken Windows tool chains > usable, without making the code worse. In fact, this patch set contains > zero code changes. That makes it unlikely to break any previously working > build. > > Employees of big companies like Intel Dell, HP, etc have site licenses to > Microsoft build tools. But what about smaller companies? Many readers of > this list have never worked for a small company. Microsoft compilers cost > several hundred US dollars per license. That kind of expense is hard to get > approved from a small company. How do you tell your manager your group needs > a set of new Visual Studio licenses because the UEFI guys at Intel won't fix > their build problems? Intel is saying F*** Y** to the small developer.
I'm an example of a developer at a (somewhat) smaller company which doesn't use Visual Studio because of licensing costs. (And because historically our engineering organization prefers Unix/Linux and isn't set up for Windows, but that's something to argue about elsewhere.) Unfortunately, we're also tied to a large body of 3rd party closed-source platform support code which doesn't build with gcc (pragmas, assembly format, etc.) So we use the DDK3790 compilers under wine, and either tweak the code or use compiler switches to suppress spurious warnings. Not ideal, but better than nothing. Has anyone tried using the compilers from the Windows 7 DDK? They are quite a bit newer than the old DDK3790. http://www.microsoft.com/en-us/download/details.aspx?id=11800 > I am pretty sure this problem of broken tool chains will never get fixed. > Even if someone who has all the Microsoft tools fixes the breakage by putting > in a bunch of code workarounds, it won't stay fixed. That is because the > current policy of enabling /WX on old Microsoft tool chains is clearly not > workable. > > The only workable solution is to do like coreboot and have only one official > tool chain. Then disable all troublesome warnings on all other tool chains. > Is there any other solution? I think not. > > I guess the big difference of opinion here is about the significance of 5 > broken tool chains. I imagine some of these have been broken for years. > What kind of first impression does that make on someone new to EDK2 when he > downloads it and tries to build it? > > Thanks, > Scott -- Brian -------------------------------------------------------------------- "My software never has bugs. It just develops random features." -- Quoted by Khan Tran ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
