ideas for C optimization wanted

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russel Winder wrote:
| On Thu, 2008-07-03 at 09:27 -0500, John Arbash Meinel wrote:
|
|> Actually, we already have some bits written in pyrex and C (pyrex is
|> python-like but can be generated into C code to be compiled.)
|>
|> While you *can* run straight from a tree, running "make" will build the
|> extensions and speed up a few common actions.
|
| Can I put in a signpost here.  Some of us run multiple architectures off
| the same filestore.  So I have Ubuntu, Solaris and Mac OS X all sharing
| a single copy of things -- see NFS can be wonderful.  SCons has very
| simple ways of dealing with this sort of compilation situation, Make on
| the other hand does not.   Of course selection of architecture at
| runtime in this sort of context has to be worried about as well.

Yeah, we build into tree so that we don't have to worry about searching
for the build products.

I've certainly used Scons for other projects, and taught the project to
run out of source with stuff like:

try:
~  import foo
except ImportError:
~  insert_build_location_into_syspath()
~  import foo

It isn't terribly pretty, and I'd like to avoid it unless it is strictly
necessary.

|
| If I have to I can run three independent copies of Bazaar simply to deal
| with this compilation, but that is definitely the Yuk! solution.
|

I wonder if you could do some sort of platform-specific symlink hackery.
Like change the foo.so to a symlink pontiign at something that would
reference the locally built module.

|> For tarball releases, we process the pyrex => C, so people don't need
|> the pyrex compiler for released code. (Sort of like including
|> Makefile.am => Makefile.in so people don't need automake.)
|
| It is good if the entire Autotools are removed and SCons is used
| instead, especially on Windows!
|
|> So I'm pretty sure we already have the build process worked out. To
|> date, we've always had python fallback code, which is almost definitely
|> something we would try to maintain. So you *can* run with 0 setup, but
|> with a bit of setup things will work even better.
|
| I bet I can find a corner case that isn't covered -- running Ubuntu,
| Solaris and Mac OS X tends to do this sort of thing to you ;-)

Actually, the bulk of the build dependencies is all wrapped into the
setup.py code. (python's distutils functionality.)

We set "make all" to do "python setup.py build_ext -i"

The reason we use a Makefile is just because it is easier for people to
remember "make" rather than the big list.

It also allows us to do some custom build steps for installing, etc.
(Make sure the docs are built first, etc.)


John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhtCjUACgkQJdeBCYSNAAOiFwCeP9Ks+wJvMKws6iK0bk/OIoS8
iNcAnRkafB0k4NisW5mQZA5P5tG6nWLy
=2iG6
-----END PGP SIGNATURE-----