olopez32 / tinypy

Automatically exported from code.google.com/p/tinypy
Other
0 stars 0 forks source link

improvements to setup.py to make it more python friendly #28

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I want setup.py to work more like this:

To build / install the Cpython API, things should work exactly how they
work for any other python module in the world:

python setup.py build
python setup.py install

To build tinypy stuff:
python setup.py tinypy (right now a platform must be specified, this should
be auto detected from sys.platform instead)
python setup.py blob (this works already)
python setup.py 64k (this works already)

Options are things like (these already work)
debug, test, boot, [optional modules to compile in]

To specify an alternate platform, the user should be able to do something
like: 
python setup.py tinypy -cmingw32

Original issue reported on code.google.com by philhas...@gmail.com on 5 Sep 2008 at 6:51

GoogleCodeExporter commented 9 years ago

Original comment by philhas...@gmail.com on 5 Sep 2008 at 6:51

GoogleCodeExporter commented 9 years ago
Most of this is not a problem, but even if we autodetect the operating system, 
we
will still need to specify the compiler manually as I see no other way of 
finding out
which to use; especially because VS works completely different than other, more 
unixy
compilers.

Original comment by denis.ka...@gmail.com on 5 Sep 2008 at 8:00

GoogleCodeExporter commented 9 years ago
VS is the default compiler on windows for python generally.  So that would be 
the
default.  To use mingw32 (which I do, for example) I'd have to supply the 
compiler
flag.  

On OSX/Linux gcc is the compiler, so no problem there either.

Original comment by philhas...@gmail.com on 5 Sep 2008 at 3:30

GoogleCodeExporter commented 9 years ago
In addition I'd like the option "valgrind" to run stuff prefixed with valgrind. 
 For
example:

python setup.py tinypy test valgrind

will build tinypy, and run the tests under valgrind.

Original comment by philhas...@gmail.com on 6 Sep 2008 at 2:49

GoogleCodeExporter commented 9 years ago
This is what the new help text should be:

python setup.py command [options] [modules]

Commands:
    tinypy - build a vanilla tinypy interpreter binary
    64k - generate a 64k version of the tinypy source
    blob - generate a single tinypy.c and tinypy.h

    build - build CPython module
    install - install CPython module

Options:
    test - run tests during build
    clean - rebuild all .tpc during build
    boot - fully bootstrap and test tinypy
    debug - build with debug options on
    valgrind - run tests through valgrind
    -cPLATFORM - build for a specific platform (for example -cmingw32)

Modules:
    math - build math module
    random - build random module *
    pygame - build pygame module **
    marshal - build marshal module ***
    jit - build jit module ***
    re - build re module ***
    ??? - build other modules in the modules folder

* coming soon!!
** proof-of-concept included
*** vaporware

Original comment by philhas...@gmail.com on 6 Sep 2008 at 6:58

GoogleCodeExporter commented 9 years ago

Original comment by ulf...@gmail.com on 16 Sep 2008 at 7:07

GoogleCodeExporter commented 9 years ago
hi,

here's some other options I noticed missing...

This is like -cmingw32, but the long form.
--compiler=mingw32

Command line programs need a help flag.
--help
/?
-h

Also a lot of people set their compiler system wide.  So you don't need to 
specify
--compiler=mingw32 all the time.  Details here:
http://docs.python.org/inst/config-syntax.html

Rather than parsing config files, it might be easier to import distutils and 
inspect
it in there somewhere.

Original comment by ren...@gmail.com on 17 Sep 2008 at 5:47

GoogleCodeExporter commented 9 years ago
Reopening while I work on the issues brought up by renesd.

Currently can't find a good way to figure out what compiler was defined in the
setuptools config file. If anyone finds a good way, let me know or just 
implement it.
I'll add support for long args and help commands soon. I'm considering 
switching us
to an actual argument parser to make all this cleaner. Feel free to share 
thoughts there.

Original comment by ulf...@gmail.com on 21 Sep 2008 at 10:36