Branko Čibej wrote:
> Russell Yanofsky wrote:
>
>> Branko Čibej wrote:
>>
>>
>>> I _still_ don't understand why you don't generate these sources in
>>> gen_win.py when the .dsp/.vcproj stuff is generated, and not from
>>> the project files themselves.
>>>
>>>
>>
>> I just want to keep the ugliness of building the swig runtime out of
>> gen-make. In general, gen-make should be limited to generating
>> makefiles and project files. If it becomes an all purpose build
>> script, it's going to turn into spaghetti and be more diffcult to
>> maintain.
>>
> There's no reason why gen-make shouldn't do that, if it's the best
> place.
I'm arguing that it's not the best place because it adds unneccessary
complexity and doesn't have anything to do with gen-make's main task of
calculating dependencies and outputting files used by build systems. Are
there any advantages at all to combining this code into gen_win.py?
> Anyway, the code generation would be don in gen_win.py, where
> we already do a bit of that -- see the bit in gen_win.__init__ where
> we generate getdate.c.
Right, this is exactly analagous to the generation of getdate.c, which is a
wart:
[from gen_win.py]
# gstein wrote:
# > we don't want to munge the working copy since we might be
# > generating the Windows build files on a Unix box prior to
# > release. this copy already occurs in svn_config.dsp. (is that
# > broken or something?)
# No, but if getdate.c doesn't exist, it won't get pulled into the
# libsvn_subr.dsp (or .vcproj or whatever), so it won't get built.
> Since the SWIG runtime sources never change
> (well, unless you install a new version of SWIG), there's no need to
> generate them during the build.
Right but this is not the issue.
> I think it's much cleaner to do so
> before.
In what sense?
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 8 03:33:53 2003