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
