You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Brandon Ehle <be...@pipedreaminteractive.com> on 2003/01/13 22:11:31 UTC
Auto generated windows projects
I've finished the last of work on the MSVC6 .dsp file generation for
windows. All that's left is for me to do some refactoring of the code.
Could you check it out and lemme know if there is anything I need to
change to be able to get this committed?
I know someone had a problem with having a modular gen-make.py, but
there were no alternatives discussed other than copying this file X
times for each of the targets and changing 3 or 4 lines of code.
Here's the current patch.
http://fishbowl.digitalbytes.net:81/svn/scripts/patch/gen-make-win32.patch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto generated windows projects
Posted by Brandon Ehle <az...@yahoo.com>.
>
>
>>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.
>
One thing that isn't set in stone right now is whether the releases come
with prebuilt project files for windows. Currently nothing has to be
configured at gen-make time, if we don't mind losing this, we could
easily generate conditional neon project files depending on whether you
want SSL or zlib, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto generated windows projects
Posted by Branko Čibej <br...@xbc.nu>.
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 <br...@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
Re: Auto generated windows projects
Posted by Brandon Ehle <be...@pipedreaminteractive.com>.
>
>
>>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.
>>
>>
>>
>
>You get these errors when you add a dependency from one static library to
>another,
>because MSVC links in the dependant lib(s). When building static libs it is best
>to
>put all the dependencies on the exes.
>
>
Unfortunately that doesn't work for Subversion because apr & aprutil
generate header files so all projects must depend on them somehow.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto generated windows projects
Posted by Chris Foote <Ch...@xtra.co.nz>.
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.
>
You get these errors when you add a dependency from one static library to
another,
because MSVC links in the dependant lib(s). When building static libs it is best
to
put all the dependencies on the exes.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto generated windows projects
Posted by Brandon Ehle <be...@pipedreaminteractive.com>.
>
>
>>+#
>>+# EXTERNAL TARGETS (NO BUILD NEEDED)
>>+#
>>+
>>+[apr]
>>+type = project
>>+path = apr
>>+libs = mswsock ws2_32 advapi32 rpcrt4 shfolder
>>+
>>+[aprutil]
>>+type = project
>>+path = apr-util
>>+libs = xml apriconv gen_uri_delims
>>+
>>+[apriconv]
>>+type = project
>>+path = apr-iconv
>>+libs = apr
>>
>>
>>
>This can't be right. First, APR doesn't need shfolder.dll; libsvn_subr
>does. Next, you seem to be assuming a static build. For a dynamic build,
>aprutil must depend on apr.
>
>
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.
>>+[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?
>>Index: subversion/libsvn_ra_dav/session.c
>>===================================================================
>>--- subversion/libsvn_ra_dav/session.c (revision 4365)
>>+++ subversion/libsvn_ra_dav/session.c (working copy)
>>@@ -239,7 +239,7 @@
>> *neon_debug = debug;
>> }
>> else
>>- *neon_debug = 0;
>>+ *neon_debug = 1073742335;
>>
>> return SVN_NO_ERROR;
>>}
>>
>>
>>
>What?
>
>
Sorry, that's a left over from tracking down a neon error.
>And a general observation: You hardcode the names and behaviour of the
>build configurations, and templates for the build scripts, in the python
>code. That makes it very hard to a) add new configuratoins, and b)
>change the scripts (or generate scripts for building DLLs, for example).
>
>
The only reason I've done this that you have to be very specific and
define things in a strict order for the output to be parseable by Visual
C++. As far as the new configurations, I've tryed to stay as modular as
I could without causing MSVC load errors.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto generated windows projects
Posted by Branko Čibej <br...@xbc.nu>.
Brandon Ehle wrote:
> I've finished the last of work on the MSVC6 .dsp file generation for
> windows. All that's left is for me to do some refactoring of the
> code. Could you check it out and lemme know if there is anything I
> need to change to be able to get this committed?
>
> I know someone had a problem with having a modular gen-make.py, but
> there were no alternatives discussed other than copying this file X
> times for each of the targets and changing 3 or 4 lines of code.
>
> Here's the current patch.
> http://fishbowl.digitalbytes.net:81/svn/scripts/patch/gen-make-win32.patch
hmmm... This is definitely not a complete review, just what I saw in a
few minutes of browsing your patch.
>+#
>+# EXTERNAL TARGETS (NO BUILD NEEDED)
>+#
>+
>+[apr]
>+type = project
>+path = apr
>+libs = mswsock ws2_32 advapi32 rpcrt4 shfolder
>+
>+[aprutil]
>+type = project
>+path = apr-util
>+libs = xml apriconv gen_uri_delims
>+
>+[apriconv]
>+type = project
>+path = apr-iconv
>+libs = apr
>
This can't be right. First, APR doesn't need shfolder.dll; libsvn_subr
does. Next, you seem to be assuming a static build. For a dynamic build,
aprutil must depend on apr.
>+[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.
>Index: subversion/libsvn_ra_dav/session.c
>===================================================================
>--- subversion/libsvn_ra_dav/session.c (revision 4365)
>+++ subversion/libsvn_ra_dav/session.c (working copy)
>@@ -239,7 +239,7 @@
> *neon_debug = debug;
> }
> else
>- *neon_debug = 0;
>+ *neon_debug = 1073742335;
>
> return SVN_NO_ERROR;
> }
>
What?
>+#Don't even get me started about this hack
>+ms_sucks_royally=[
>
>
I sympathize, but you should really chose more descriptive names.
>Index: build/gen_vcnet.py
>===================================================================
>--- build/gen_vcnet.py (working copy)
>+++ build/gen_vcnet.py (working copy)
>
>
The contents of this file seem to be pasted twice.
>Index: build/gen_bcpp.py
>===================================================================
>--- build/gen_bcpp.py (working copy)
>+++ build/gen_bcpp.py (working copy)
>@@ -0,0 +1,46 @@
>+#
>+# gen_win32.py -- generate windows projects
>+#
>
>
And this one.
>Index: build/win32/installer.bat
>===================================================================
>--- build/win32/installer.bat (working copy)
>+++ build/win32/installer.bat (working copy)
>@@ -0,0 +1,5 @@
>+@echo Creating windows installer...
>+
>+"C:\Program Files\My Inno Setup Extensions 3\iscc" ..\..\packages\win32-innosetup\svn.iss.%1
>+
>+
>
>
Hardcoded location again.
>Index: packages/win32-innosetup/svn.iss.in
>===================================================================
>--- packages/win32-innosetup/svn.iss.in (working copy)
>+++ packages/win32-innosetup/svn.iss.in (working copy)
>@@ -0,0 +1,338 @@
>
>
You should coordinate with Jostein about the innosetup thing.
And a general observation: You hardcode the names and behaviour of the
build configurations, and templates for the build scripts, in the python
code. That makes it very hard to a) add new configuratoins, and b)
change the scripts (or generate scripts for building DLLs, for example).
The generated build scripts (at least the .dsp's) should always have
CRLF line endings, regardless of the platform they were generated on.
win-tests.py should be changed to modify the abs_builddir for the target
configuration.
Please, don't think I don't appreciate the efort you put in this. It's
just that I'd like to see these scripts become really useful.
--
Brane Čibej <br...@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