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 2002/12/13 16:16:56 UTC
[PATCH] gen-make-modular.patch
Here's the first patch for the windows project file generation.
* autogen.sh: Pass -c in front of build.conf when running gen-make.py
* gen-make.py, build/gen_make.py: Make gen-make.py modular so that we
can add the windows project file generation targets.
* build/gen_base.py: Remove obsoleted MSVC stuff
http://fishbowl.digitalbytes.net:81/svn/scripts/patch/gen-make-modular.patch
Re: [PATCH] gen-make-modular.patch
Posted by Branko Čibej <br...@xbc.nu>.
Brandon Ehle wrote:
> So you'd rather have about 8 different gen-*.py scripts in the
> toplevel directory (once all the windows project file modes are done)?
>
> Please note that some of the gen-*.py scripts for windows will consist
> of:
>
> gen-msvc-dsp.py
> gen-msvc-nmake.py
> gen-mingw.py
> gen-vcnet-vcproj.py
> gen-vcnet-nmake.py
> gen-bcpp-bpr.py
> gen-bcpp-make.py
Heh. Some drivers will be closely related -- I submit that MinGW would
use makefiles just like Unix, and those would of course be generated by
get-make.py. The .dsp and .vcproj generators should be closely related
too, I expect. And I see no reason to generate both project files and
makefiles; one or the other, but both is overkill.
> You'd rather have all those scripts sitting in the toplevel directory
> in addition to gen-make.py,
No, I'd rather have all those scripts somewhere in build/, where they
belong.
> or would you rather have one gen-make.py script that can invoke any of
> the above (and you can even pass it the "all" parameter to generate
> everything)?
I would not. The Windows scripts have to handle things like the location
of httpd sources, the location of apr/apr-util/apr-iconv and neon, and
BDB... in short, a lot of things that configure takes care of on Unix. I
see no read on to put that logic into gen-make.py, because it clearly
doesn't belong there.
Keep things modular. One huge do-it-all script is a pain to maintain.
--
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: [PATCH] gen-make-modular.patch
Posted by Brandon Ehle <be...@pipedreaminteractive.com>.
>
>
>> [etc.]
>>
>> I don't like this change at all. You're mixing apples and oranges.
>> gen-make.py generates makefiles, not .dsp's. The requirements are
>> substantially different; you're complicating the driver script
>> needlessly. The dsp generator should have its own driver script.
>>
>>
> So you'd rather have about 8 different gen-*.py scripts in the
> toplevel directory (once all the windows project file modes are done)?
>
> Please note that some of the gen-*.py scripts for windows will consist
> of:
>
> gen-msvc-dsp.py
> gen-msvc-nmake.py
> gen-mingw.py
> gen-vcnet-vcproj.py
> gen-vcnet-nmake.py
> gen-bcpp-bpr.py
> gen-bcpp-make.py
>
> You'd rather have all those scripts sitting in the toplevel directory
> in addition to gen-make.py, or would you rather have one gen-make.py
> script that can invoke any of the above (and you can even pass it the
> "all" parameter to generate everything)?
>
Ooh, and I forgot to mention that they will all contain the same code
with about 4 lines of code different between them if we go the
non-modular route.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] gen-make-modular.patch
Posted by Brandon Ehle <be...@pipedreaminteractive.com>.
>
>
>>- def __init__(self, fname, verfname, oname):
>>+ def __init__(self, fname, verfname, oname=None):
>> gen_base.GeneratorBase.__init__(self, fname, verfname)
>>
>>+ if not oname:
>>+ oname = os.path.splitext(os.path.basename(fname))[0] + '-outputs.mk'
>>+
>> self.ofile = open(oname, 'w')
>> self.ofile.write('# DO NOT EDIT -- AUTOMATICALLY GENERATED\n\n')
>>
>>
>>
>Why are you doing this? It's not the module's job to guess the output
>file name; that should be done by the output script, the way it was done
>before.
>
>
I fail to see the point of this, only the module know what its
outputing, if we drop this in the driver script then the we have to
special case every module in the driver.
>[etc.]
>
>I don't like this change at all. You're mixing apples and oranges.
>gen-make.py generates makefiles, not .dsp's. The requirements are
>substantially different; you're complicating the driver script
>needlessly. The dsp generator should have its own driver script.
>
>
So you'd rather have about 8 different gen-*.py scripts in the toplevel
directory (once all the windows project file modes are done)?
Please note that some of the gen-*.py scripts for windows will consist of:
gen-msvc-dsp.py
gen-msvc-nmake.py
gen-mingw.py
gen-vcnet-vcproj.py
gen-vcnet-nmake.py
gen-bcpp-bpr.py
gen-bcpp-make.py
You'd rather have all those scripts sitting in the toplevel directory in
addition to gen-make.py, or would you rather have one gen-make.py script
that can invoke any of the above (and you can even pass it the "all"
parameter to generate everything)?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] gen-make-modular.patch
Posted by Branko Čibej <br...@xbc.nu>.
Brandon Ehle wrote:
> Here's the first patch for the windows project file generation.
>
> * autogen.sh: Pass -c in front of build.conf when running gen-make.py
>
> * gen-make.py, build/gen_make.py: Make gen-make.py modular so that we
> can add the windows project file generation targets.
>
> * build/gen_base.py: Remove obsoleted MSVC stuff
[snip]
>Index: build/gen_make.py
>===================================================================
>
...
>- def __init__(self, fname, verfname, oname):
>+ def __init__(self, fname, verfname, oname=None):
> gen_base.GeneratorBase.__init__(self, fname, verfname)
>
>+ if not oname:
>+ oname = os.path.splitext(os.path.basename(fname))[0] + '-outputs.mk'
>+
> self.ofile = open(oname, 'w')
> self.ofile.write('# DO NOT EDIT -- AUTOMATICALLY GENERATED\n\n')
>
Why are you doing this? It's not the module's job to guess the output
file name; that should be done by the output script, the way it was done
before.
>Index: gen-make.py
>===================================================================
>--- gen-make.py (revision 4111)
>+++ gen-make.py (working copy)
>
[etc.]
I don't like this change at all. You're mixing apples and oranges.
gen-make.py generates makefiles, not .dsp's. The requirements are
substantially different; you're complicating the driver script
needlessly. The dsp generator should have its own driver script.
>+# This doens't truly need to be here, but its possible
>+# you don't have all the python modules that project files
>+# require, but you don't want to build them anyway.
>+def load_build_modules(list):
>+ for modname in list:
>+ try:
>+ # Attempt to import the modules list of targets from generators variable
>+ mod = __import__(modname)
>+
>+ for gendef in mod.generators.items():
>+ # Attempt to import the modules actual target classes
>+ generator_dict[gendef[0]] = getattr(mod, gendef[1])
>+
>+ except ImportError:
>+ traceback.print_exc()
>+ print>>sys.stderr, "warning: Failed to import module 'build/%s.py'." % modname
>+ print>>sys.stderr, " Targets from this module will not be available."
>+ print>>sys.stderr, " See the backtrace above if you wish to resolve this issue."
>+ print>>sys.stderr
>
See? ths is unnecessary complication.
--
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