[Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies

noreply@sourceforge.net noreply@sourceforge.net
Fri, 07 Dec 2001 07:49:01 -0800


Bugs item #472881, was opened at 2001-10-19 11:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Michael Hudson (mwh)
Summary: distutils does not deduce dependencies

Initial Comment:
I just "cvs up"d my Python tree and executed "make".
Nothing much changed, except patchlevel.h.  Make got
this right and rebuilt everything (patchlevel.h is
included from Python.h, so changing patchlevel.h
should cause make to rebuild just about everything).

Distutils failed to notice this, however, so it didn't rebuild any modules.  In this case, I think the
failure to rebuild is probably innocuous, but I'm
not at all confident it will do the right thing if I
modify some other file.  For example, I've noticed
that it's not sufficient to delete a module's .o file
when you want to rebuild it.  Distutils still thinks
the .so file is okay.

If distutils is going to take the place of make I
think it's going to need to do a much better job
deducing file dependencies or provide a robust
way for a person to tell it what those dependencies
are.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2001-12-07 07:49

Message:
Logged In: YES 
user_id=6656

OK, I'll try to get something concrete done in the next few
days.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-07 06:54

Message:
Logged In: YES 
user_id=6380

It depends on what kind of change you are making to a header
file. 99% of the time I find that a change to a header is
something innocuous like add a new function, and it still
causes a rebuild of the world. That's particularly annoying
when I'm experimenting with a new object type and adding
things to the header file one at a time -- each time the
header gets touched everything gets rebuilt.

But it's easy enough to only rebuild the core ("make
python") so I'm not sure if I really oppose your simple
solution.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-07 05:53

Message:
Logged In: YES 
user_id=6656

Eh, I was going to add a os.system("touch last_build")
thingy to setup.py.  Not aiming for elegance here.

Is it really 99% of the time that changes in headers are
irrelevant?  Then what make does is a bit silly, surely.

It would presumably be easy enough to ask the user, but I
know I'd find that really annoying (I generally fire a biuld
off, do something else for a few minutes and come back. 
OTOH, I almost always go through a "rm -rfv build && mkdir
build && cd build && ../configure --prefix=$HOME && make"
ritual anyway so this issue doesn't affect me in the slightest).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-07 05:40

Message:
Logged In: YES 
user_id=6380

Hm, how do you know when the last build was?

Also, since in 99% of the cases this is unnecessary and
rebuilding all extensions takes a long time, I'd like this
to be optional -- maybe it can ask the user before zapping
build?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-07 04:36

Message:
Logged In: YES 
user_id=6656

Would a "good enough" solution be to check (in setup.py) if
pyconfig.h or anything in Include/ has changed since the
last build and if so blow away the & build directory?

Doing a "proper" job seems frankly unlikely, and would have
much the same effect as the above anyway for building Python...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470