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

Re: [PATCH] Intergrating the build of javahl binding into the main build system on Windows

From: Patrick Mayweg <mayweg_at_qint.de>
Date: 2004-06-07 06:46:10 CEST

Hi DJ,

D.J. Heap wrote:

> Patrick Mayweg wrote:
>
>> Hi,
>> I have worked on integrating the build of the javahl into the main
>> build system on Windows. This integration has been done for the non
>> Windows platform by Justin Erenkrantz earlier.
>>
>> The main problem was that to compile on Windows "custom build" step
>> are needed for compiling the java classes (javac) and generating the
>> JNI include files (javah). "custom build" steps exist for the swig
>> bindings. The problem is that those are hard coded in the template
>> files (msvc_dsp.ezt and vcnet_vcproj.ezt) and in gen_win.py. Other
>> targets need "custom build" steps too. So I have remove the hard
>> coded rules from the template files and moved the generation into
>> gen_win.py. The next decision was where to put the code to generate
>> the "custom build" steps for javac and javah. I have put this code
>> into 2 new methods into TargetJavaClasses and TargetJavaHeaders in
>> gen_base.py. This seamed to be more logical then to put the code into
>> get_proj_sources (gen_win.py).
>>
>> Other targets which need "custom build" steps would have to implement
>> those 2 methods ("get_windows_custom_build" and
>> "get_windows_custom_target") and to set the marker
>> "needs_windows_custom_build" of the target.
>>
>> The option extra-classes for TargetJavaHeaders is not need anymore
>> since r9907.
>>
>> Any commets?
>>
> [snip]
>
> I'm playing catch-up, so I apologize for the late comments...

No problem.

>
> I haven't looked this over in heavy detail, but with this patch could
> we also get rid of the svn_config.dsp, neon.dsp, and svn_locale.dsp
> files that are also just very simple custom build projects? If it
> involves having to change more python code, can it be generalized
> enough so that we can just tweak build.conf and get rid of those dsp's
> (and duplicated vcproj's) entirely?

I do not know what these projects do in their custom buid step, but I
think that can be generalized and put into build.conf, so we can dump
the dsp's and vcproj's. But I would like to separate projects which
contain just one or two custom build steps and java related projects,
which have a custom build step for every source file. AFAIK the Swig
custom build steps fall in the first category.

>
> It doesn't seem very far from what you've got in this patch (if it
> can't currently do it). Would you mind taking a look at how that
> could be done?

I can look into it, but would like to commit the javahl related patch
first.

>
> DJ

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 7 06:47:01 2004

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.