Sorry. I must have replied to the wrong email. I see now that it was the 11/11 patch.
On 1/16/2016 3:41 PM, Chris Pavlina wrote: > You're looking at a totally different patch than this thread is about. > You seem to do that a lot, maybe check that your email client is > threading correctly? ;) > > > On Sat, Jan 16, 2016 at 03:40:11PM -0500, Wayne Stambaugh wrote: >> Huh? >> >> +// MSVC doesn't have __func__ >> +#ifdef _MSC_VER >> +#define __func__ __FUNCTION__ >> +#endif >> + >> >> It's been a long time since I've used MSVC but I'm pretty sure that the >> _MSC_VER is MSVC specific. >> >> https://msdn.microsoft.com/en-us/library/b0084kay.aspx >> >> On 1/16/2016 3:31 PM, Nick Østergaard wrote: >>> Wayne, please keep in mind that the patch does not add an ifdef MSVC >>> or anything similar. Did you even look at the patch file? >>> >>> 2016-01-16 21:23 GMT+01:00 Wayne Stambaugh <[email protected]>: >>>> I'm pretty sure I've discussed this with Simon before but maybe it was >>>> someone else. We removed all of the MSVC foo from KiCad years ago >>>> because it just made the code horrid and it was all over the place. >>>> Whenever I see a check for MSVC, this says to me that this code is >>>> specific to MSVC. Devs who want to use MSVC should keep the MSVC >>>> specific code in their personal repos. Maybe some time I will be able >>>> to embrace MSVC. Today is not that day. We have much bigger issues to >>>> resolve than getting KiCad to build on MSVC. >>>> >>>> On 1/16/2016 2:39 PM, Chris Pavlina wrote: >>>>> Hmm. From my perspective, I didn't really think it was a policy >>>>> violation as such, as that is definitely not MSVC-specific. It's just >>>>> "portable", which is generally a good thing - if we were ever to change >>>>> the current policy in the future, the more portable the code is, the >>>>> easier that will be. And who knows, it's possible we could have to do >>>>> that in the future, if current toolchains are abandoned or something. >>>>> >>>>> Personally I have absolutely no problem with making things more portable >>>>> when there is no added complexity and nothing compiler-specific - I'd >>>>> probably have committed this if you hadn't replied before I could get >>>>> around to testing it. >>>>> >>>>> Fair enuogh about not wanting to directly support MSVC, of course, I >>>>> don't want that either. :) >>>>> >>>>> >>>>> On Sat, Jan 16, 2016 at 02:34:18PM -0500, Wayne Stambaugh wrote: >>>>>> Please do not commit this patch. The current policy is no MSVC specific >>>>>> code in KiCad and I'm not interested in changing that policy any time >>>>>> soon. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Wayne >>>>>> >>>>>> On 1/15/2016 11:41 PM, Simon Richter wrote: >>>>>>> >>>>>>> Windows-style dllimport/dllexport should be used whenever targetting >>>>>>> Windows directly, not just for MINGW. >>>>>>> >>>>>>> --- >>>>>>> include/import_export.h | 2 +- >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>> Post to : [email protected] >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>> Post to : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
