It's not difficult to test if a debian/rules file is in fact a makefile, and if it does support a target.
Firstly, a test to see if something is a makefile can be as simple as reading the first line of the file -- does it contain #!/usr/bin/make -f (as policy dictates in 5.2) Secondly, make -q can be called. If it returns with an exit code of 1 or 0, the target is supported. If it returns with 2, it isn't supported. >From Bug#72335 (debian-policy: [ACCEPTED 10/6/2001] Optional build-arch and build-indep targets for debian/rules): The question of how to handle the use of this is still a little contentious: the simplest way is for dpkg-buildpackage to run debian/rules -q build-arch when building arch-specific binaries only and examine the return status. But this assumes that debian/rules is a makefile. This was the subject of a flame-war some while ago which was never resolved. But this proposal makes sense nevertheless; if we lose the requirement that debian/rules has to be a makefile, then we can either stipulate that debian/rules has to behave like a makefile wrt -q, or we can have dpkg-buildpackage checking the #! line to see whether it is a makefile. Either way, it has the potential of saving autobuilders some work in some cases and resolves the Build-Depends-Indep semantical error. I'd like to see this bug resolved. It just doesn't seem right for each buildd to build the irrelevant parts of my package (spamassassin) that are written in perl so that one measly C binary is built. Thanks, -- Duncan Findlay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
