On Wed, Nov 11, 2009 at 10:16 PM, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
> > Ouch, That's not to be done. Something is wrong with your build_clib > design here. > You are roughly calling "install" as a sub command. Yes, it is "wrong" from distutils POV, but there is no other solution to get the prefix. The problem is that prefix is available in install, not that I want to know the prefix when building. > > If you want to have install options for your command, and if your > command is about "installing", I did not say my command was about installing - it does not install anything. To be complete, we do not use this in build_clib, but in build_src , to generate pkg-config-like files (build_src is a numpy.distutils-specific command to build source files, for example automatically generated wrappers around fortran libraries, and is typically run before any other build_ command) > > For build_clib, if you need to build something, it goes in the > build_dir, or in place., and this is not impacted > by the install command. That's exactly the problem. build + install description is too simplistic for complex builds: you often need to know install options at build time. You need to know some build options when building configuration files, you need to pass configuration options to other subsequent steps, etc... > > This is similar to getting the command, (instanciate it + finalize it > if it doesn't exists yet) > and return a finalized option. This does not solve the issue IMHO. Since we both seem to like thinking about use-cases, consider this use-case: you have a python package with a complex extension built with make (say you have a build_make command which calls a makefile). How do you do it ? How to communicate path informations, compiler options between make and distutils ? How to handle relinking (changing rpath at install time) ? >> >> I will try to document how scons does it. I think the basic idea could be >> reused in distutils. > > But, you didn't answer: if we add the ability to define a different > compiler for each Extension, > will it solve your use case ? I did not answer because my answer will take time to accurately summarize tools problems in build tools. We have discussed quite a bit about those issues in scons as well and I want to be sure that my answer takes this into account as well. > > If you are willing to spend some time in that, I am the guy who can > commit your patches in Python. I will try to prepare a couple of patches against the hg repo this WE, David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
