[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] [patch #8790] Add support for Visual Studio Builds
From: |
Joerg Wunsch |
Subject: |
Re: [avrdude-dev] [patch #8790] Add support for Visual Studio Builds |
Date: |
Mon, 16 Nov 2015 23:09:32 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)