On Mon, Mar 16, 2015 at 12:39 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Mon, Mar 16, 2015 at 9:50 AM, Chris Angelico <rosuav@gmail.com> wrote:
The tricky part here is defining the oldest supported version. "To
build Python X.Y, you must already have Python ??? or later installed"
- how do you pick the minimum? The older that minimum, the more warped
the build code has to be

sure -- but it seems what's on the table now is: must be buildable by an old version of C -- not even C99 which is nominally 16 years old...

So yeah, the build system itself would need to support a "old" python -- though probably python2.7 would be OK at this point -- sorry, not py3 yet, but what can you do?

> If there is an already build python (like OS-X, any general purpose linux
> distro, Windows if you don't mind point and clicking the python.org
> installer, etc, then it's not really a "bootstrap".

No, that's not what I'm talking about. I'm talking about trying to
build Thunderbird and having to do a bunch of steps where I run this
program, then run that, then let it chug its way through stuff, and
then eventually it'll start building.

It sounds like that build setup suck, yes -- but not sure why that's relevant. Clearly we don't want something that ugly. We want something that is both easy and robust to configure for new platfroms, etc, and easy on the end user to "jsut build" the source. All I"m proposing that is requireing a not-very-recent python as a first step is only a big hurdle for folks poritn got new platforms -- your use case would be, in INSTALL.txt:

"""
1) You need at least python 2.7 to build this software. 

try:

python --version

if it starts up and reports a version greater than 2.7, then you are all set. If not, then It can probably be installed with your system package manager:

apt_get install python

or similar. On Windows, you can download an installer for Python2.7 from python.org

2) Once a python is working, you can build the this latest version from source with:

./buildme
"""

Of course, there may be options, etc, but that's the basic deal.

And heck, if people REALLY want the ./configure && make && make install dance, then we could ship a little configure script that does nothing but call the python-based one...

Of course, all this is predicated on there BEING some miraculous as-powerful-and-flexible-and-robust-as-autotools-but-much-easier-to-use python-based build system.....

One more note: so adding a python dependency is a pain. But the current system requires separate stems for Windows and *nix-y systems, and who knows what for hypothetical systems that don't support autotools. So maybe a python-based build system that worked on all the common platforms, with an additional makefile that you have to hand-mangle to bootstrap a new platform isn't any more to maintain.


The best build systems I know in Python are fbuild, Waf, and Meson. Meson generates Ninja scripts, and Ninja's in C++, so that's out of the question.

I have used fbuild a LOT and can say that, after you get through the small amount of command-line boilerplate, it works very well. It's also very easy to extend with host/target compiler differences. Not sure about Waf, but I do know it does about anything you'd guess.

I guess this narrows the result down to Boost.Build or a Python-based build system.
 
-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.