Re: [Openocd-development] Fwd: SWD?

2011-09-26 Thread Akos Vandra 
Also, I get a build error for ./src/transport/swd_libswd_drv_openocd.c.
I suspect it is because I have an x64 system where pointers are 64bits in size.
The lines listed below try to cast a pointer to an int (signed 32bit),
for producing log messages.
I don't know why the address pointed is useful log information, and
don't really know how to make this
piece of code portable between 32bit and 64bit systems, so I'll leave
it up to you.

I quick-fixed it for my machine by changing the cast to (long long
int), and adjusting the printf argument to %LX. That way it builds.

The errors are:

swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_8’:
swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_32’:
swd_libswd_drv_openocd.c:90: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:90: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_miso_8’:
swd_libswd_drv_openocd.c:131: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:131: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:131: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_miso_32’:
swd_libswd_drv_openocd.c:159: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:159: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:159: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_trn’:
swd_libswd_drv_openocd.c:174: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_miso_trn’:
swd_libswd_drv_openocd.c:201: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_log_level_inherit’:
swd_libswd_drv_openocd.c:228: error: cast from pointer to integer of
different size

Regards,
  Ákos

On 26 September 2011 00:02, Akos Vandra axo...@gmail.com wrote:
 Hi!

 Thank you for the advice, I will do my best to live up to them :)

 I'm new to git as well, I tried making the patch you requested:

 Cheers,
  Ákos

 From 88a430100be4d9685863aa2912173ddc5b83e92f Mon Sep 17 00:00:00 2001
 From: Akos akos@FM12BQ.(none)
 Date: Sun, 25 Sep 2011 23:55:36 +0200
 Subject: [PATCH] Fixed two warnings for uninitialized variables
 generating build errors

 Two retvals in the functions oocd_swd_transport_init and
 mem_ap_read_buf_u32 have not had their values initialized
 and generated a warning, which cause the build to fail.
 Fixed by initializing these variables to ERROR_OK
 ---
  src/target/arm_adi_v5.c  |    2 +-
  src/transport/swd_core.c |    2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
 index f529446..1454007 100644
 --- a/src/target/arm_adi_v5.c
 +++ b/src/target/arm_adi_v5.c
 @@ -696,7 +696,7 @@ int mem_ap_read_buf_u32(struct adiv5_dap *dap,
 uint8_t *buffer,
  //     uint32_t invalue, adr = address;
  //     uint8_t* pBuffer = buffer;

 -       int i, retval;
 +       int i, retval = ERROR_OK;
        uint32_t invalue;
        //count = 2;
  //     wcount = count;
 diff --git a/src/transport/swd_core.c b/src/transport/swd_core.c
 index 383199f..36191fb 100644
 --- a/src/transport/swd_core.c
 +++ b/src/transport/swd_core.c
 @@ -125,7 +125,7 @@ int oocd_swd_run(struct adiv5_dap *dap){
  // TODO: We are operating on global interface pointer, change it into
 function parameter asap.
  int oocd_swd_transport_init(struct command_context *ctx){
        LOG_DEBUG(entering function...);
 -       int retval, *idcode;
 +       int *idcode, retval = ERROR_OK;

        struct target *target = get_current_target(ctx);
        struct arm *arm = target_to_arm(target);
 --
 1.7.1


 On 25 September 2011 23:15, Peter Stuge pe...@stuge.se wrote:
 Hi Akos,

 Akos Vandra wrote:
 Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu).

 10.10 is soon one year old, which can be a long time in open source.

 Also keep in mind that pretty much every major distribution is
 applying significant amounts of patches in their toolchain packages
 and possibly also system libraries.

 They intend this to make things better of course, but it can backfire
 and make the toolchain unusable sometimes. Keep this in mind if you
 encounter a weird build issue of any package.

 From many years of use of gcc and binutils I would recommend to use
 a vanilla toolchain, or at the very least very aggressively pulling
 toolchain updates from your distribution.


 I have been getting some warnings (treated as errors) due to some
 retvals didn't have initial value set, but I set them to ERROR_OK,
 and now it passes those points.

 Please send patch(es) for these to the mailing list. Thanks!

Re: [Openocd-development] Fwd: SWD?

2011-09-26 Thread Peter Stuge 
Akos Vandra wrote:
 I suspect it is because I have an x64 system where pointers are 64bits in 
 size.
 The lines listed below try to cast a pointer to an int (signed 32bit),
 for producing log messages.
 I don't know why the address pointed is useful log information, and
 don't really know how to make this piece of code portable between
 32bit and 64bit systems, so I'll leave it up to you.

I think %p should work.


//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Fwd: SWD?

2011-09-26 Thread Tomek CEDRO 
On Mon, Sep 26, 2011 at 11:48 AM, Peter Stuge pe...@stuge.se wrote:
 Akos Vandra wrote:
 I suspect it is because I have an x64 system where pointers are 64bits in 
 size.
 The lines listed below try to cast a pointer to an int (signed 32bit),
 for producing log messages.

 I think %p should work.

Yup, it works perfectly, thank you Peter! There are however some older
places where I did not fix that, will happen this afternoon :-)

Best regards,
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Fwd: SWD?

2011-09-26 Thread Peter Stuge 
Akos Vandra wrote:
 Thank you for the advice, I will do my best to live up to them :)

Cool.


 I'm new to git as well, I tried making the patch you requested:

Some feedback. First, please see if you can send patches as
text/plain attachments (optionally with a Content-Disposition: inline
MIME header) because when they are included in the body of the
message usually they will be destroyed somehow by either the sending
or the receiving email software. :\


 From 88a430100be4d9685863aa2912173ddc5b83e92f Mon Sep 17 00:00:00 2001
 From: Akos akos@FM12BQ.(none)

Please fix this to look nice by running:

git config --global user.name 'Akos Vandra'
git config --global user.email 'y...@email.addr'

And then please fix the authorship information for this commit. You
will now already jump into one of the most powerful features of git;
rewriting history. Recommend reading Pro Git on this topic:
http://progit.org/book/ch6-4.html

So if this is the last commit on the branch that you are working with
then run git commit --amend --author='Akos Vandra y...@email.addr'
and save the commit message. NB I think you need a not too old
version of git for --author to work. It's possible that what is in
Ubuntu 10.10 is too old. :\ In that case you can still do it, but it
gets a bit more complicated.

You need to say --author because git tracks authorship separate from
who committed. Run git log --pretty=fuller to see both fields. The
user.(name|email) settings will only be used for Commit information
when doing git commit --amend, because even though you are making a
new commit it does not mean that you are now suddenly the author of
this change, so you have to manually set a new Author on the command
line.


 Date: Sun, 25 Sep 2011 23:55:36 +0200
 Subject: [PATCH] Fixed two warnings for uninitialized variables
 generating build errors
 
 Two retvals in the functions oocd_swd_transport_init and
 mem_ap_read_buf_u32 have not had their values initialized
 and generated a warning, which cause the build to fail.
 Fixed by initializing these variables to ERROR_OK

Why was ERROR_OK in particular chosen?

Is it the common pattern in other functions? Or did you check these
two functions in detail to discover that the unused variable will be
used in the success case?

It is a good idea to not neccessarily focus on *what* is changed
(when this can trivially be learned from the patch itself) but
more importantly discuss *why* the change was made in the particular
way it was.


 +++ b/src/target/arm_adi_v5.c
 @@ -696,7 +696,7 @@ int mem_ap_read_buf_u32(struct adiv5_dap *dap,
 uint8_t *buffer,
  //   uint32_t invalue, adr = address;
  //   uint8_t* pBuffer = buffer;
 
 - int i, retval;
 + int i, retval = ERROR_OK;
..

 +++ b/src/transport/swd_core.c
 @@ -125,7 +125,7 @@ int oocd_swd_run(struct adiv5_dap *dap){
  // TODO: We are operating on global interface pointer, change it into
 function parameter asap.
  int oocd_swd_transport_init(struct command_context *ctx){
   LOG_DEBUG(entering function...);
 - int retval, *idcode;
 + int *idcode, retval = ERROR_OK;

Ideally try to always change as few bytes as possible in every patch.
Some patches will be large anyway, but it is a good idea to not
change extra things, such as the reordering of variable
declarations here. It will work also to initialize retval if it
remains first on the line, so this is preferable. Some diff
algorithms are smart enough to visualize this change as only being
new characters added after retval, so swapping the order adds noise.

This change is probably perfectly fine, but in this case the patch
itself is not enough for a reviewer to judge, since the only thing we
see is your commit message saying I changed it to return ERROR_OK
where there was a warning for uninitialized variable and we see this
one more time in the patch, but we don't see the code that is
affected by this change, so it's impossible to say if your fix is
right or wrong. :\ The easiest way is to have more *why* and less
*what* in the commit message.


//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Fwd: SWD?

2011-09-26 Thread Tomek CEDRO 
On Mon, Sep 26, 2011 at 9:27 AM, Akos Vandra axo...@gmail.com wrote:
 swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_8’:
 swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
 different size
 swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
 different size
 (..)

Fixed, commit sent, thanks for verification! printf now use %p for
(void*)pointer :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Fwd: SWD?

2011-09-25 Thread Tomek CEDRO 
Regarding the LibSWD and OpenOCD relationship:

OpenOCD use LibSWD git submodule from the libswd git repository tag
v0.2 which can differ a bit from the head. I am working on the v0.2
and periodically add those changes to head. v0.2 is meant to build off
the shelf as it has configure scripts pre-compiled, so it will become
libswd-0.2 release and it can be used direclty within OpenOCD without
bootstrapping (or even autotools generation). You can clone libswd tag
v0.2 and it should build right away after ./configure, please let me
know if that works for you, if not then I need to fix the libswd, if
it does then we need to check the openocd trunk sources (probalby the
types.h file).

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Fwd: SWD?

2011-09-25 Thread Akos Vandra 
Hi!

Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu).

I have been getting some warnings (treated as errors) due to some
retvals didn't have initial value set, but I set them to ERROR_OK, and
now it passes those points.

Right now build gets stuck at

In file included from ../../src/helper/command.h:26,
 from ../../src/helper/log.h:29,
 from swd_libswd_drv_openocd.c:42:
../../src/helper/types.h:115: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘le_to_h_u32’
../../src/helper/types.h:120: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘le_to_h_u24’
../../src/helper/types.h:125: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘le_to_h_u16’
../../src/helper/types.h:130: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘be_to_h_u32’
../../src/helper/types.h:135: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘be_to_h_u24’
../../src/helper/types.h:140: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘be_to_h_u16’

It seems like uint32_t is not defined, even though it should be, as
stdint.h is included.
Funny thing, if I set the first occurance of uint32_t to unsigned int,
the other ones build fine, which is kinda wierd.

Working on it...

I'll try to spam you less 'til mid october then, I have some work to
finish myself, but I have to get going with my thesis as well. :)

Also, should we spamming the developer list, or rather continue this
discussion personally? I'm not familiar with opensource development
*at all*, so I'm not familiar with list policies either.


Cheers,
  Ákos




On 25 September 2011 18:28, Tomek CEDRO tomek.ce...@gmail.com wrote:
 On Sun, Sep 25, 2011 at 4:03 PM, Akos Vandra wrote:
 I'm trying to follow your instructions here
 http://stm32primer2swd.sf.net/ but I cannot find the interface script
 for kt-link-swd.
 I tried cloning the openocd git repo from here:
 git://openocd.git.sourceforge.net/gitroot/openocd/openocd

 The openocd-libswd trunk repository is
 git://repo.or.cz/openocd/libswd.git the http interface is at
 http://repo.or.cz/w/openocd/libswd.git

 Please tell me what is your build environment, I use FreeBSD, there
 were some issues with Linux build, but I fixed some of them (mainly on
 LibSWD, still there may be some in openocd), please let me know what
 does not work. I will setup virtual machine with your build
 environment and try to help you. I think Linux Ubuntu is the most
 common Linux distro nowadays..?

 I have been extremely overworked recently, please call me on chart for
 critical issues, I should have more time on mid October (~2..3 weeks)
 but I will support you as much as I can meanwhile :-)

 My hardware is not a kt-link, but it *should* work, because the SWD
 pinout is the same.

 The pin definitions are now taken out to the TCL / configuration file,
 so they should be not hardcoded (except standard FT2232 pins but we
 shout bring them out anyway) and easy to match any other interface
 with no need to rewrite the sources :-)

 Best regards! :-)
 Tomek


 --
 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Fwd: SWD?

2011-09-25 Thread Tomek CEDRO 
On Sun, Sep 25, 2011 at 4:39 PM, Akos Vandra axo...@gmail.com wrote:
 Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu).

cool :-) i will prepare the vm then :-)

 ../../src/helper/types.h:140: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
 ‘__attribute__’ before ‘be_to_h_u16’

exactly, types.h. Please take a look at the original openocd types.h
maybe this is working and we will know what is wrong :-)


 I'll try to spam you less 'til mid october then, I have some work to
 finish myself, but I have to get going with my thesis as well. :)

no problem, i can give you some hints almost right away but i can get
to the code for serious in 2...3 weeks. I also finish my diploma,
currently waiting for an exam, this is the last delay cause ;-)

 Also, should we spamming the developer list, or rather continue this
 discussion personally? I'm not familiar with opensource development
 *at all*, so I'm not familiar with list policies either.

On one hand it may be good information source for other people that
want to get into SWD/SWO, so we can post here. We can also post
private to minimize the message amount. Let the other developers
decide, both options are good for me :-) If you are not that familiar
with the development I would also recommend to get into OpenOCD's
internals first as it tool some considerable amount of time for me to
guess whats going on :-) I can see the reason to better document the
SWD work, I will do it in the openocd manual after my diploma exam :-)

Best regards,
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Fwd: SWD?

2011-09-25 Thread Peter Stuge 
Hi Akos,

Akos Vandra wrote:
 Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu).

10.10 is soon one year old, which can be a long time in open source.

Also keep in mind that pretty much every major distribution is
applying significant amounts of patches in their toolchain packages
and possibly also system libraries.

They intend this to make things better of course, but it can backfire
and make the toolchain unusable sometimes. Keep this in mind if you
encounter a weird build issue of any package.

From many years of use of gcc and binutils I would recommend to use
a vanilla toolchain, or at the very least very aggressively pulling
toolchain updates from your distribution.


 I have been getting some warnings (treated as errors) due to some
 retvals didn't have initial value set, but I set them to ERROR_OK,
 and now it passes those points.

Please send patch(es) for these to the mailing list. Thanks!


 It seems like uint32_t is not defined, even though it should be, as
 stdint.h is included.

stdint.h is included only #ifdef HAVE_STDINT_H. Did you verify with
gcc -E or at least in config.h that HAVE_STDINT_H is defined?


 Funny thing, if I set the first occurance of uint32_t to unsigned
 int, the other ones build fine, which is kinda wierd.

It is not funny at all. I find it typical of a toolchain issue. It is
bullshit that wastes precious developer time. :\


 Also, should we spamming the developer list,

Certainly yes. The purpose of the developer list is to carry
developer discussion.


 or rather continue this discussion personally?

Absolutely not.


 I'm not familiar with opensource development *at all*,

Welcome to open source! It can be a wonderful environment of
cooperation and synergy when things align well. It can also be a
challenging environment of conflicts and complaints when they don't.

Overall I personally find it to be more than worth the trouble, and
I think it leads to better software.


 so I'm not familiar with list policies either.

Again, this is a developer list whose sole purpose is for developer
communication. Direct communication should be an exception.
(Sometimes it's the right thing of course, just usually it is not.)

Please study git and work on becoming fluent with it if you are not
already. It is a great tool that supports development in very many
ways. Beyond simply keeping track of what happened in the code git
when used well allows incredibly efficient review and movement of
code between developers in a project. I can recommend the
http://progit.org/ book, but start out by just playing with it a
little. Make some repositories with some commits and get the basic
workflow going. Learning the rest is usually easy. I also recommend
the #git IRC channel on freenode, for getting live help.


One use for developer mailing lists is to distribute proposed
patches, so that they can be reviewed and then included into the
public source tree.

To make the review step quick and thus make it somewhat likely to
actually happen, it is *critical* that the patch is what I call
clean. Maybe all this is obvious to you already, in that case
please skip to bottom. The individual points of a clean patch are:


* Write a top quality commit message, technically and logically

In git repositories it is useful to follow a certain commit message
format: (Line numbers added to the left)

1. Description of change, prefer =60 chars, absmax 74 or even 72 chars
2. 
3. Third line and onward hold longer description of change
4. each line absmax 74 chars

The first line is used in list views, where one commit is listed per
line. This makes it important to have a short and sweet description
of the change in the first line. The second line is always left
blank. The third line and any number of following lines can and
should include background on this part of the code and discuss why
this change was made the way it was done instead of some other more
obvious way. Ie. document the research that went into this particular
change of the code. Including links to web pages with relevant
information is helpful, as is links to mailing list messages e.g. on
http://marc.info/ which has nice short message links. (Only the m=
URL parameter is required for links to a message.)

The line length restrictions are in part due to use of 80 char wide
terminals, but more importantly they are due to how patches are sent
and refered to in email. I.e. even if in an open source project no
active developer is using 80 char wide terminals there may be
participants on the mailing list who benefit from the shorter lines,
in which case it makes sense to keep them short. Also, web based
repository viewers tend to not want or be able to present very long
first line descriptions.

As for the logical quality, it is important to write the first line
description of the change so that it makes sense for someone who
knows nothing at all about the code, since this is used in list
views, and since the background for

Re: [Openocd-development] Fwd: SWD?

2011-09-25 Thread Akos Vandra 
Hi!

Thank you for the advice, I will do my best to live up to them :)

I'm new to git as well, I tried making the patch you requested:

Cheers,
  Ákos

From 88a430100be4d9685863aa2912173ddc5b83e92f Mon Sep 17 00:00:00 2001
From: Akos akos@FM12BQ.(none)
Date: Sun, 25 Sep 2011 23:55:36 +0200
Subject: [PATCH] Fixed two warnings for uninitialized variables
generating build errors

Two retvals in the functions oocd_swd_transport_init and
mem_ap_read_buf_u32 have not had their values initialized
and generated a warning, which cause the build to fail.
Fixed by initializing these variables to ERROR_OK
---
 src/target/arm_adi_v5.c  |2 +-
 src/transport/swd_core.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index f529446..1454007 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -696,7 +696,7 @@ int mem_ap_read_buf_u32(struct adiv5_dap *dap,
uint8_t *buffer,
 // uint32_t invalue, adr = address;
 // uint8_t* pBuffer = buffer;

-   int i, retval;
+   int i, retval = ERROR_OK;
uint32_t invalue;
//count = 2;
 // wcount = count;
diff --git a/src/transport/swd_core.c b/src/transport/swd_core.c
index 383199f..36191fb 100644
--- a/src/transport/swd_core.c
+++ b/src/transport/swd_core.c
@@ -125,7 +125,7 @@ int oocd_swd_run(struct adiv5_dap *dap){
 // TODO: We are operating on global interface pointer, change it into
function parameter asap.
 int oocd_swd_transport_init(struct command_context *ctx){
LOG_DEBUG(entering function...);
-   int retval, *idcode;
+   int *idcode, retval = ERROR_OK;

struct target *target = get_current_target(ctx);
struct arm *arm = target_to_arm(target);
-- 
1.7.1


On 25 September 2011 23:15, Peter Stuge pe...@stuge.se wrote:
 Hi Akos,

 Akos Vandra wrote:
 Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu).

 10.10 is soon one year old, which can be a long time in open source.

 Also keep in mind that pretty much every major distribution is
 applying significant amounts of patches in their toolchain packages
 and possibly also system libraries.

 They intend this to make things better of course, but it can backfire
 and make the toolchain unusable sometimes. Keep this in mind if you
 encounter a weird build issue of any package.

 From many years of use of gcc and binutils I would recommend to use
 a vanilla toolchain, or at the very least very aggressively pulling
 toolchain updates from your distribution.


 I have been getting some warnings (treated as errors) due to some
 retvals didn't have initial value set, but I set them to ERROR_OK,
 and now it passes those points.

 Please send patch(es) for these to the mailing list. Thanks!


 It seems like uint32_t is not defined, even though it should be, as
 stdint.h is included.

 stdint.h is included only #ifdef HAVE_STDINT_H. Did you verify with
 gcc -E or at least in config.h that HAVE_STDINT_H is defined?


 Funny thing, if I set the first occurance of uint32_t to unsigned
 int, the other ones build fine, which is kinda wierd.

 It is not funny at all. I find it typical of a toolchain issue. It is
 bullshit that wastes precious developer time. :\


 Also, should we spamming the developer list,

 Certainly yes. The purpose of the developer list is to carry
 developer discussion.


 or rather continue this discussion personally?

 Absolutely not.


 I'm not familiar with opensource development *at all*,

 Welcome to open source! It can be a wonderful environment of
 cooperation and synergy when things align well. It can also be a
 challenging environment of conflicts and complaints when they don't.

 Overall I personally find it to be more than worth the trouble, and
 I think it leads to better software.


 so I'm not familiar with list policies either.

 Again, this is a developer list whose sole purpose is for developer
 communication. Direct communication should be an exception.
 (Sometimes it's the right thing of course, just usually it is not.)

 Please study git and work on becoming fluent with it if you are not
 already. It is a great tool that supports development in very many
 ways. Beyond simply keeping track of what happened in the code git
 when used well allows incredibly efficient review and movement of
 code between developers in a project. I can recommend the
 http://progit.org/ book, but start out by just playing with it a
 little. Make some repositories with some commits and get the basic
 workflow going. Learning the rest is usually easy. I also recommend
 the #git IRC channel on freenode, for getting live help.


 One use for developer mailing lists is to distribute proposed
 patches, so that they can be reviewed and then included into the
 public source tree.

 To make the review step quick and thus make it somewhat likely to
 actually happen, it is *critical* that the patch is what I call
 clean. Maybe all this is obvious to you