kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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 <stambaughw@xxxxxxxxx>:
>>>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>