>
>
>>A couple of notes:
>>
>>* Do we want to store the .dsp, .vcproj, & .bprs in build/win32/msvc6,
>>build/win32/vcnet, etc. or store them in subversion/libsvn_subr,
>>subversion/clients/cmdline like we do now?
>>
>>
>
>We don't want to store them in the repository at all. Instead, they
>should be generated in build/win32/<config>, with <config> being the
>build configuration -- static vs. dynamic, release vs. debug vs.
>purify-enabled, etc. The binaries should be generated below that
>directory, in appropriate subdirs mirroring the source tree, so that the
>test scripts can find them.
>
>
Will make this change by Wednesday.
>>* Currently static builds are the default. This is because DLL
>>building on windows is fairly broken.
>>
>>
>
>What do you mean? If you're haveing trouble exporting global symbols,
>well, there are ways to fix that. In the end, we'll probably have to do
>something similar to what APR_DECLARE does.
>
>
There is definitely alot of symbol export errors, but there are also
some memory management across DLL boundary issues. Will give some more
detail info on this once static build stuff is done.
>>* I am copying config.cw to config.c before running the .dsp generator
>>as the glob won't find config.c if its not there. My recommendation
>>to cleanup the config.cw is to move it into a subdirectory of
>>libsvn_subr/win32 and rename it to config.c in that directory, then
>>add a win32 hook to add that dirs files only when building for win32.
>>
>>
>
>What's wrong with the way it's done now -- i.e., have the build scripts
>generate the .c from the .cw? you have to do the same for .hw->.h, too.
>
>
The first problem I noticed is that gen_make doesn't find the .c file
when you are building and therefore doesn't add it to the files list for
the project. This could be hacked around, but then you get into other
stuff related to delaying this copy and I'm not sure the benefits of a
late copy is worth all the extra effort (KISS)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 2 05:13:49 2002