On 06/23/2012 02:27 PM, Vinay Sajip wrote: > Dag Sverre Seljebotn<d.s.seljebotn<at> astro.uio.no> writes: > >> As for me, I believe I've been rather blunt and direct in my criticism >> in this thread: It's been said by Tarek that distutils2 authors that >> they don't know anything about compilers. Therefore it's almost >> unconceivable to me that much good can come from distutils2 *for my >> needs*. Even if packaging and building isn't the same, the two issues do >> tangle at a fundamental level, *and* most existing solutions already out >> there (RPM, MSI..) distribute compiled software and therefore one needs >> a solid understanding of build processes to also understand these tools >> fully and draw on their experiences and avoid reinventing the wheel. > > But packaging/distutils2 contains functionality for hooks, which can be used to > implement custom builds using tools that packaging/distutils2 doesn't need to > know or care about (a hook will do that). One can imagine that a set of > commonly used templates would become available over time, so that some problems > wouldn't need to have solutions re-invented. Of course you can always do anything, as numpy.distutils is a living proof of. Question is if it is good design. Can I be confident that the hooks are well-designed for my purposes? I think Bento's hook concept was redesigned 2 or 3 times to make sure it fit well... >> Somebody with a deep understanding of 3-4 existing build systems and >> long experience in cross-platform builds and cross-architecture builds >> would need to be on board for me to take it seriously (even the >> packaging parts). As per Tarek's comments, I'm therefore pessimistic >> about the distutils2 efforts. > > This deep understanding is not essential in the packaging/distutil2 team, > AFAICT. They just need to make sure that the hook APIs are sufficiently > flexible, that the hooks invoked at the appropriate time, and that they are > adequately documented with appropriate examples. > > For me, the bigger problem with the present distutils2/packaging implementation > is that it propagates the command-class style of design which IMO caused so > much pain in extending distutils. Perhaps some of the dafter limitations have > been removed, and no doubt the rationale was to get to something usable more > quickly, but it seems a bit like papering over cracks. The basic low-level > building blocks like versioning, metadata and markers should be fine, but I'm > not convinced that the command-class paradigm is appropriate in this case. The > whole intricate "initialize_options"/"finalize_options"/"set_undefined_options" > /"get_finalized_command"/"reinitialize_command" dance just makes me say, And of course, propagating compilation options/configuration, and auto-detecting configuration options, is one of the most important parts of a complex build. Thus this seem to contradict what you say above. (Sorry all, I felt like I should answer to a direct challenge. This will be my last post in this thread; I've subscribed to distutils-sig.) Dag
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4