On Wed, Nov 11, 2009 at 2:48 PM, David Cournapeau <courn...@gmail.com> wrote: >> 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) >
But you call it with "install" in your example, meaning that is is called at install time, right ? Or it is just that you want to get the "--prefix" value finalized and computed by the install command. If it's the later, I guess you will be able to use the upcoming "sysconfig" module, that gives you the install schemes, depending on sys.prefix/sys.exec_prefix. And I will probably add a way to override those prefix, meaning that you will be able to get from your command all install paths depending on a root prefix. If not, it means that you are doing a post or pre install step during installation. e.g. like RPM's pre/post commits hooks. >> >> 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... Sorry, I can see it yet, it still fuzzy. Does that mean your binary distribution will not be relocatable ? e.g. meaning that once you have done your build for a given --prefix, it won't be installable anywhere else ? In that case you would need to remove the --prefix option from install, and have it on your build command. Sounds like a pre/post install hook but I am not sure. >> 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 don't know for the first part. I have to try it out. Can you provide me such an extension ? For the relinking at installation time problem, it is obvious that something can be done. we could have a pre/post install option where an arbitrary command could be launch, as an install subcommand. pre: works on the build_dir built by install or a previous build. post: works on the installed file list [..] >> 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, yeah, thanks ! \o/ Tarek _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig