Re: [avrdude-dev] [patch #8790] Add support for Visual Studio Builds

[Wes Witt]

Thanks. All feedback incorporated and a new patch submitted.

-Wes

-----Original Message-----
From: Joerg Wunsch [mailto:address@hidden 
Sent: Monday, November 16, 2015 2:10 PM
To: address@hidden
Cc: Wes Witt <address@hidden>
Subject: Re: [patch #8790] Add support for Visual Studio Builds

As Wes Witt wrote:

> In answer to your question about the #ifdef change in jtag3.c, the 
> change was made because the code inside my #else block makes reference 
> to libusb variables, structures, etc. that are not present when 
> HAVE_LIBUSB is not defined. Basically the change just prevents some 
> code from being compiled when there is no LIBUSB support.

I don't see any libusb stuff out there, but there are references to other 
USB-related things, and it obviously doesn't make sense to even think about 
compiling that when there's no libusb around.

> Finally, I need some clarification about the change to stk500. I 
> understand the desire for uniformity here -- great. I'm not sure what 
> you're suggesting the change be?  On Windows we need tp use alloca in 
> the case because the code is declaring a stack variable whose size is 
> determined at runtime.

Sorry, I confused the direction of the patch, you are right.

About alloca(), buspirate.c already contains the sequence:

#if defined(WIN32NATIVE)
#  include <malloc.h>
#endif

and then uses alloca() below in the code (without the leading underscore).

Would it be OK for you to use the same style?

> If we want the same code on Windows & Linux don't we need to use 
> alloca in both cases?

Feel free to change it like that.  As I already said, the existing code base 
makes use of C99 features wherever it seemed appropriate, but rather than 
adding more #ifdef spaghetti, I'd use alloca() for everyone then.  GCC used to 
support this for many years anyway.  (In the end, C99 variable-length arrays 
are nothing else but a special case of implying alloca() for their allocation.)

I'd prefer to have #ifdef _MSC_VER_ only for those things that depend on the 
Visual C compiler environment, and rather use WIN32NATIVE for general 
platform-dependend code for a Windows target, i.e. things that are also 
applicable when compiling with MinGW - just to keep in mind.

Just as background information: the unixoid part of the code base is by far not 
restricted to Linux environments.  AVRDUDE started out on FreeBSD (that's my 
main development platform), but also compiles on OSX, Solaris to the least, and 
of course, on the other BSD derivatives.  When developers keep in mind to 
separate platform-dependant stuff in only a few places, it's not all that 
difficult to maintain a vastly platform-independant application.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fwww.sax.de%2f~joerg%2f&data=01%7C01%7Cwesw%40microsoft.com%7C3b457fa7eea042e5d8a108d2eed29c23%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=4yBKMSQrcR8ay5TFaGq5kdCJ6ggL8FVx9Rz4gRxg3fw%3d
Never trust an operating system you don't have sources for. ;-)