Martin v. Löwis wrote: > If that is so, just ignore the warnings.
Not acceptable, because it means I have to examine all the warnings every time I compile to check that another one hasn't appeared that represents a real problem. > one way to solve the problem is to make the warnings > go away. The most straightforward way to solve the problem is not to ask for these warnings in the first place. Or at least it would be if I had a decent amount of control over what warnings get asked for. > I'm wondering what a make-like system would look > in this case. Would I write > > $(TARGETDIR)/foo/bar.py: foo/bar.py > cp foo/bar.py $(TARGETDIR)/foo/bar.py Don't take "make-like" too literally. All I mean is something organised around a dependency graph rather than a list of things to do one after the other. The nodes in the graph needn't be individual files. The whole package-to-be-build would be a node, which would depend on the nodes representing the .py files. The specification would probably look fairly similar in some ways to what you currently pass to the setup function, i.e. a list of .py files that go into the package. But the internal structure would be built out of dependency graph nodes rather than commands and sub-commands. > If you look at Python's "make install" rule, you > might agree that "install" is not something that > plain old make is very good at. I agree that Make itself doesn't handle install-type operations very well. I think that's partly because it's too rigidly fixated on a target being a single file. -- Greg _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
