bzr-windows team mailing list archive

[Vincent Ladeuil <v.ladeuil+lp@xxxxxxx>]

>>>>> "jam" == John Arbash Meinel <john@xxxxxxxxxxxxxxxxx> writes:

<snip/>

    jam> I'm not sure what you mean about "defining more commands".

I mean... making more internals accessible from the command line.

    jam> You can define new targets by creating a Builder class,
    jam> and adding it to the list of supported actions, etc. Or
    jam> you can override a builder class (as we do with
    jam> build_ext to have --allow-python-fallbacks.)

But this didn't give me enough control to address
https://bugs.edge.launchpad.net/bzr/+bug/385453, which is the
main reason the fix for it stalled.

Basically (as I remember it) you need pyrex to know how the C
files are named, and you need the C file names when pyrex is not
available. The C file names are built in setup.py, you need them
in the Makefile.

I found only hackish ways to address that, the proper way is to
get rid of the Makefile for that and rely on python only.

    jam> If you mean "have qbzr tell setup.py about its
    jam> dependencies" that was never done.

That's is certainly another case, yes.

The problem, as I view it,is that we are a bit schizophrenic
between Makefile and setup.py.

I think we should put more features into setup.py and less in
Makefile.

Easier said than done, but I wanted it to say it anyway :)

I thought for a long time that more things could be done in the
Makefile, but I now realize that getting totally rid of the
Makefile is preferable.

And the recent discussions about the docs and the problems I
encountered on FreeBSD all points in the same direction: setup.py
is better suited to address our needs and we'll get better
features and better tests by building on that.

       Vincent