[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Auto generated windows projects

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-01-14 00:14:00 CET

Brandon Ehle wrote:

> Haven't managed to get dynamic builds linking yet do to some API
> stuff, I planned on adding a static / dynamic switch one the initial
> stuff gets in. On this note, aprutil depends on apriconv which
> depends on apr, if I make aprutil depend on apr as well, MSVC6 croaks
> trying to compile with tons of duplicate defined symbols.

Yes, I know. I also know the solution -- it's similar to what APR is
doing, only a bit more complicated, because we have to take cross-DLL
linkage into account. Well, no matter, we can address the dynamic build
later.

>>> +[neon]
>>> +type = external
>>> +path = neon
>>> +sources = neon/src/*.c
>>> +cmd = ..\build\win32\build_neon.bat
>>> +release = libneon.lib
>>> +debug = libneonD.lib
>>>
>>>
>>
>> So I'll have a .dsp generator, but I'll still have to edit
>> build_neon.bat to make it link with zlib and openssl? I _said_ I didn't
>> want to push everything into gen-make.py, because the Windows build
>> scripts will need options like --with-zlib. It would also be nice to be
>> able to point to the location of apr, apr-util, apr-iconv, BDB, ... all
>> of which is handled by the configure script on Unix, but has to go
>> somewhere else on Windows.
>>
>>
> Neon's makefile system is a mess, I've almost considered making a
> project for it with build.conf rules for windows builds. Or would you
> rather try to hack around the neon project files straight from the
> author?

Hehe, be careful here -- *I* am the author of the neon Windows makefile,
and our build_neon.bat. :-)
The reason it's not as simple as you'd like is that project files simply
aren't flexible enough, and neon can build and link with a lot of
different options. A makefile was the only sane solution.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 14 00:15:06 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.