Re: Need someone to test my win32 .dsp generator scripts

[Brandon Ehle <be...@pipedreaminteractive.com>]

 >
  >
  >>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

Re: Need someone to test my win32 .dsp generator scripts

[Mark Brown <br...@sirena.org.uk>]

On Mon, Dec 02, 2002 at 08:43:33PM +0100, Branko ??ibej wrote:
> Brandon Ehle wrote:

> > some memory management across DLL boundary issues.  Will give some more
> > detail info on this once static build stuff is done. 

> Hm, I don't understand that. Memory is owned by the process, regardless
> of DLL boundaries. I'd be interested to see what problems you're running
> into.

I don't know if this is the issue being discussed but with Visual Studio
there are multiple versions of the C runtime library.  If you manage to
get several of them linked into the same process then they each use
separate malloc() arenas and get very upset if you try to do something
like free memory with the wrong copy of free().

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Need someone to test my win32 .dsp generator scripts

[Branko Čibej <br...@xbc.nu>]

Brandon Ehle wrote:

>  >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, 

Yes, those have to be fixed on the source level.

> 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. 

Hm, I don't understand that. Memory is owned by the process, regardless
of DLL boundaries. I'd be interested to see what problems you're running
into.

>  >>* 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)

Ah, I see. Well, it's not as if getdate.cw will change often.

-- 
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