autoconf (was Re: [Box Backup] 0.08PLUS3)

[Joe Krahn]

Martin Ebourne wrote:
> Ben Summers <ben@fluffy.co.uk> wrote:
> 
>> To be honest, I'm scared at all the changes which will be necessary,
>> and can't see any easy way around the binary / library / test structure
>> of the project without lots of scary sub targets.
> 
> 
> I'm sure the current directory layouts would not be hard to preserve. As 
> for
> the way the targets work in the test directories it's quite possible it
> would be necessary to change how they work currently. I'm sure we could 
> come
> up with a scheme which would be perfectly functional.
> 
> After all, change might be scary, but that doesn't make it bad.
> 
>> The Win32 native stuff was the bit which would require the changes to
>> the build system. Although I don't think it'll be that bad, I think I
>> can get away with post-processing the output for a BSD.
> 
> 
> Obviously the major change is windows and that makes it a good time to look
> at completely new solutions. I don't advocate autoconf because of windows,
> but because in the long term I'm sure that it is the only sensible way to
> get good cross platform support on unix. I think history has proven this
> many times, even if just by the number of projects which have abandoned
> their own build systems for autoconf over the years. Even the ACE library,
> with its huge very cross platform home-grown build system is finally going
> autoconf. They've got 27,000 files in the full distribution, that must be a
> lot of work!
> 
> The trick would be to go autoconf and make it work with windows too, then
> we'd get best of both worlds.
I still think autoconf is a good idea, much better than the Windows-world's
non-portable project files. It just requires installing Cygwin, and I can't
understand why any serious Windows developer would not want Cygwin.
Aside from autoconf, it's the best way to get a decent 'make'.


> 
>> I'd like to use the free MS compiler for the Win32 port. I believe it
>> has better code, but more importantly, it's a different compiler which
>> will help keep the code clean and compliant. Just using one compiler
>> for a "portable" project is slightly non-optimal.
> 
> 
> I agree, and had assumed that actually. Although gcc is the obvious choice
> with cygwin, it is possible to use ms's own compiler. See:
> 
> http://cccl.sourceforge.net/
I haven't looked there, but using VC's cl.exe is easy.
I've already done a partial build of boxbackup using Cygwin/GnuMake
with cl.exe from VC7. I used a precompiled OpenSSL binary, so that
part was easy. Here's a summary of the porting issues so far:

VC doesn't support the 'LL' suffix; is uses 'i64'. My solution was to change
1234LL to LL(1234), and define LL as a macro.

In BoxPlatform:
     VC has no stdint.h, so I added typedefs for uint16_t, etc.
     The structure pack() pragmas work.

Socket differences: Win32 has sockaddr instead of sockaddr_un, and
it's a bit different - easy to fix. There's also several socket header 
includes
that need to be moved into BoxPlatform.h

Win32 has no opendir() function, only a file find function, but it can do
recursion for you. Win32 also has a function to actively monitor filesystem
changes. Maybe this could be used instead of polling.

Overall, it looks fairly easy. But, I didn't look at the server code, 
just client
code. For my purposes, I am only am interested in Windows client code
anyhow. The server will always be Linux or other POSIX.

Joe