[CLN-list] MinGW64 build

[Alexei Sheplyakov]

Hello,

On Fri, Aug 10, 2012 at 03:43:46PM +0100, Robert Szalai wrote:
 
> What do you think I need to do to port CLN to LLP64 model.

long within CLN has (at least) 3 meanings:

1. An integer as large as a pointer.
2. On a 64-bit platform: a 64-bit integer.
3. Just long (say, in conversion functions).

One need to classify every occurrence and replace 1) with (u)intptr_t,
2) with int64_t, and leave 3) as is.

> Also if I manage to carry this out, would you be interested in merging it?

That depends. A mega-patch without any explanation at all (like the one
you've already sent) would be certainly rejected (sorry, we want CLN to
be a bit maintainable). 
 
The suggestions below can greatly increase the chances of your changes
being accepted:

1. Split your changes into separate self-contained patches. For instance,
   if the changes include both bug fix and performance enhancement(s),
   separate those changes into two (or even more) patches. On the other hand,
   if you make a single change to numerous files (like API update), group
   those changes into a single patch.
2. Describe your changes: explain what problem you are trying to solve, what
   are you doing to solve it, and why you are taking a particular approach.
3. Mind the performance, please.
4. Don't introduce regressions (in particular, build failures are not
   appreciated at all).
5. Don't add (even more) compiler- and OS-specific code unless it's
   absolutely necessary.
6. Don't mix platform specific platform specific code with generic one (put
   the platform specific code into a different function, macros, file, etc).

@ developers: should we add `How to submit patch' entry to the FAQ?
   
> > It's a type tag. Its purpose is to distinguish between the immediate
> > values (small integers, short floats) and the actual pointers. See
> > include/cln/object.h for more details.
> 
> Quite interesting way of saving space.

The point is that small objects (integers) are allocated on the stack which
is *much* faster than allocating them in the heap. So actually it's a way
to improve the performance.


Best regards,
	Alexei