This will be my last CMake patch, so this is the one you want to
commit. Others can then take it from here.
background material on cross compiling with this support:
http://www.cmake.org/Wiki/CmakeMingw
http://vtk.org/Wiki/CMake_Cross_Compiling#Using_executables_in_the_build_created_during_th
On Sun, 2009-05-03 at 01:43 +0200, Michael Bruck wrote:
> On Sun, May 3, 2009 at 1:03 AM, Zach Welch wrote:
> > On Sun, 2009-05-03 at 00:40 +0200, Michael Schwingen wrote:
> >> Zach Welch wrote:
> >> > If the header is required, the configure step should fail when it is not
> >> > found in the sys
On Sun, May 3, 2009 at 1:03 AM, Zach Welch wrote:
> On Sun, 2009-05-03 at 00:40 +0200, Michael Schwingen wrote:
>> Zach Welch wrote:
>> > If the header is required, the configure step should fail when it is not
>> > found in the system. The rule is to fail as early as possible.
>> >
>> > Which he
On Sun, 2009-05-03 at 00:40 +0200, Michael Schwingen wrote:
> Zach Welch wrote:
> > If the header is required, the configure step should fail when it is not
> > found in the system. The rule is to fail as early as possible.
> >
> > Which headers?
> >
> Not system headers - I was thinking about
On Fri, 2009-05-01 at 23:30 -0400, Gene Smith wrote:
> If you build openocd with --enable-rlink (or probably with other options
> that use USB) and at least usb.h is not present in the system headers,
> you get a build failure.
>
> "./configure --enable-rlink" does not check for presence of usb.h
Zach Welch wrote:
> If the header is required, the configure step should fail when it is not
> found in the system. The rule is to fail as early as possible.
>
> Which headers?
>
Not system headers - I was thinking about in-project headers (either
user-edited, config.h or similar) that define s
On Sat, 2009-05-02 at 12:26 +0200, Michael Schwingen wrote:
> Zach Welch wrote:
> > With autotools, #ifdef should be preferred. For example, HAVE_FOO_H
> > will be defined 1 by the AC_CHECK_HEADERS([foo.h],[1],[Comment]) macro;
> > configure defines the symbol to the given value if foo.h is prese
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Isn't it much easier to write the conditional based on what causes it
rather that what doesn't. unistd.h in _general_ doesn't include
environ. Either write a test for autoconf that tries to use environ
when only unistd.h is included or do the getopt hack:
/* If __GNU_LIBRARY__ is not alre
On Sat, May 2, 2009 at 12:26 PM, Michael Schwingen
wrote:
> Zach Welch wrote:
>> With autotools, #ifdef should be preferred. For example, HAVE_FOO_H
>> will be defined 1 by the AC_CHECK_HEADERS([foo.h],[1],[Comment]) macro;
>> configure defines the symbol to the given value if foo.h is present,
If it is a GNU specific thing then assuming that more often than not
this package is used with glibc I would suggest keeping
#if !HAVE_UNISTD_H || IS_DARWIN
rather than listing all variations that have environ in unistd.h.
As an alternative a test in ./configure would be a solution.
Michael
Hi,
On Sat, May 2, 2009 at 6:52 PM, Strontium wrote:
> Hi,
>
> I've been playing with the Flyswatter, OpenOCD and my Beagle Board.
>
> And I would like to see the serial output from the beagle, routhed
> through the B port of the flyswatter, but for some reason, it seems
> OpenOCD via libftdi (v0
Hi,
I've been playing with the Flyswatter, OpenOCD and my Beagle Board.
And I would like to see the serial output from the beagle, routhed
through the B port of the flyswatter, but for some reason, it seems
OpenOCD via libftdi (v0.13) is blocking up the whole FT22232 Device,
regardless that on
Michael Schwingen a écrit :
> Zach Welch wrote:
>
>> Sheesh. One religious war per week isn't enough? ;) We made it past
>> the C vs C++ language war only to be caught up in whitespace wars? :)
>>
>>
> Just my thought. We have had this discussions - what, half a year ago?
>
> I do not
On May 2, 2009, at 15:36, Michael Fischer wrote:
> the new version r1589 do not solve the problem,
> becasue the unistd.h looks like:
>
> #define getpagesize() PAGE_SIZE
>
> No information about environ here.
I believe declaring environ in unistd.h is a glibc-ism and on other
systems you have t
Hello,
the new version r1589 do not solve the problem,
becasue the unistd.h looks like:
#define getpagesize() PAGE_SIZE
No information about environ here.
Regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
http
I committed Zach's fix for these warnings just now.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mai
Hello List,
I have problem to build jim.c under Mac OS X.
Here the old version looks like:
static int Jim_EnvCoreCommand(Jim_Interp *interp, int argc,
Jim_Obj *const *argv)
{
const char *key;
char *val;
if (argc == 1) {
#ifndef _WIN32
extern char **environ;
#endif
Zach Welch wrote:
> With autotools, #ifdef should be preferred. For example, HAVE_FOO_H
> will be defined 1 by the AC_CHECK_HEADERS([foo.h],[1],[Comment]) macro;
> configure defines the symbol to the given value if foo.h is present, and
> the symbol is not defined if absent. In both cases, the d
Dick Hollenbeck wrote:
> We have an uncrustify.cfg file that infers a certain style. That was
> accepted into the project months ago. By inference I could have run the
> entire source file through uncrustify and I suppose you would have
> whined even more.
>
That should have been a separate
Zach Welch wrote:
> Sheesh. One religious war per week isn't enough? ;) We made it past
> the C vs C++ language war only to be caught up in whitespace wars? :)
>
Just my thought. We have had this discussions - what, half a year ago?
I do not understand why such taste discussions have to pop u
On Sat, 2009-05-02 at 10:02 +0200, Øyvind Harboe wrote:
> So it has come to pass: CMake can do stuff that automake can not
> do.
>
> This is what we feared :-)
>
> Should we embrace CMake as providing features that automake doesn't
> do or should we insist that automake is updated?
I would say
On Sat, 2009-05-02 at 10:29 +0200, Kees Jongenburger wrote:
> Hello Zach,
>
> First of all I value good discussion and many point you bring up.
>
> On Sat, May 2, 2009 at 10:10 AM, Zach Welch wrote:
> > On Sat, 2009-05-02 at 01:01 -0500, Dick Hollenbeck wrote:
> >> I have never seen a project th
Dick Hollenbeck wrote:
> It extremely hard to mis-interpret the width of a space, and my hard
> disk, compiler, and eyes cannot tell the difference.
>
> What are you seeing when you look at tms_seq? Does it look nice and
> organized neatly into columns?
>
The first block looks equally borked
On Sat, 2009-05-02 at 10:45 +0200, Øyvind Harboe wrote:
> What does this patch do?
Looks like it fixes the link for the DLL build by moving those symbols
into a file that does not contain main(). It may be better to add a
httpd_stub.c file though, given my understanding of how thinks link up.
Ch
What does this patch do?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-devel
Hello Zach,
First of all I value good discussion and many point you bring up.
On Sat, May 2, 2009 at 10:10 AM, Zach Welch wrote:
> On Sat, 2009-05-02 at 01:01 -0500, Dick Hollenbeck wrote:
>> I have never seen a project that needs to be forked as badly as this
>> one. You sit around and nit pic
On Fri, 2009-05-01 at 20:25 -0500, Dick Hollenbeck wrote:
> Fixes some problems. Has worked on OS2, Linux, Windows, Cygwin now.
>
> It generates both openocd executable and also now a libopen-ocd.so file
> for folks wanting to make a shared object / DLL. That would be me. I
> think I want to
On Sat, 2009-05-02 at 07:04 +0200, Michael Bruck wrote:
> I would like to start another holy war while we are at it:
>
>
> 1. Are false preprocessor variables in OpenOCD specified by not
> defining a variable or by defining it as 0 ?
OpenOCD's variables are defined as 0 or 1. This is not standa
On Sat, 2009-05-02 at 01:01 -0500, Dick Hollenbeck wrote:
> > Dick,
> >
> > Once again, "it's not you, it's me." Blah, blah, blah :)
> >
>
> English please. No idea what the above sentence is saying.
It meant "do not take this personally, it's my opinion." The "blah blah
blah" was beca
So it has come to pass: CMake can do stuff that automake can not
do.
This is what we feared :-)
Should we embrace CMake as providing features that automake doesn't
do or should we insist that automake is updated?
Personally I don't need those new features, but if you dig to the
depths of the mai
Index: src/openocd.c
===
--- src/openocd.c (revision 1588)
+++ src/openocd.c (working copy)
@@ -228,6 +228,21 @@
int httpd_start(void);
void httpd_stop(void);
+
+#if !BUILD_HTTPD
+/* implementations of OpenOCD that uses multithre
What about those that do not care about whitespaces?
I don't want to read a 100 page document, nor do I want to participate
in any discussions
Can we have a tool that automatically reformats and stores .c/.h
code in some defined format in SVN using hooks? :-)
Also, I've developed white space
33 matches
Mail list logo
