Re: Do not create conditional installation directories
Ralf Wildenhues wrote: * Ralf Corsepius wrote on Tue, Mar 17, 2009 at 12:08:44PM CET: Allan Caffee wrote: On Sun, 15 Mar 2009, Ralf Wildenhues wrote: There is another downside: up to now, one could use something like foo_DATA = to let $(DESTDIR)$(foodir) be created at installation time. This of course no longer works, and as such is a backward incompatibility. Was this ever a documented feature? No as far as I know. I don't recall, but I know it is widely used and therefore will cause silent incompatibilities between the next automake version and its predecessors. To me personally, it's a severe functional regression. Well, here we have an item where one's bug is another person's feature. Right, and you are throwing away a _useful_ feature, pushing around users. BTW, a 'make distcheck' or a 'make install' into a fresh prefix should be able to uncover this incompatibility, so while it is silent, it is not the most silent thing there is. But the question remains: how do you think we should address the bug that bothers Akim, other than by this patch and a big warning in NEWS? IMO, there is no bug. There simply is lack of documentation, documenting a behavior some users don't expect, they could easily work-around inside of their Makefile.am, which rarely has caused mal-functions. What you are doing now is _breaking_ what used to work == regression. Ralf
Re: [PATCH 11] Fix LAZY_TEST_SUITE handling and $(TEST_SUITE_LOG) recreation.
Hello Akim, addressing part of your reply: * Akim Demaille wrote on Sat, Mar 14, 2009 at 03:00:42PM CET: > Le 14 mars 09 à 14:46, Ralf Wildenhues a écrit : >> * Akim Demaille wrote on Sat, Mar 14, 2009 at 02:25:03PM CET: >>> FWIW, I also noticed that we sometimes had tests that were removed/ >>> renamed that were still marked as XFAILs. So I use this in some of >>> my test suites: >> >> Why are these not simply treated as hard failures? > > Hum, I don't understand what you mean here, they are. My code checks > that members of XFAIL_TESTS and TFAIL_TESTS exist, and reports the > missing ones. Never mind. I misunderstood your prior message completely. Your rule can be simplified a lot: :-) # Check that XFAIL tests do exist. check-test-list-XFAIL: $(XFAIL_TESTS) check-test-list-TFAIL: $(TFAIL_TESTS) .PHONY: check-test-list-XFAIL check-test-list-TFAIL Of course that will also update the actual tests if they are generated themselves, but IIUC then that should not be a problem for you. You could even check-local: check-test-list-XFAIL check-test-list-TFAIL Cheers, Ralf
Re: Do not create conditional installation directories
* Ralf Corsepius wrote on Tue, Mar 17, 2009 at 12:08:44PM CET: > Allan Caffee wrote: >> On Sun, 15 Mar 2009, Ralf Wildenhues wrote: >>> There is another downside: up to now, one could use something like >>> foo_DATA = >>> >>> to let $(DESTDIR)$(foodir) be created at installation time. This of >>> course no longer works, and as such is a backward incompatibility. >> >> Was this ever a documented feature? No as far as I know. > I don't recall, but I know it is widely used and therefore will cause > silent incompatibilities between the next automake version and its > predecessors. > > To me personally, it's a severe functional regression. Well, here we have an item where one's bug is another person's feature. BTW, a 'make distcheck' or a 'make install' into a fresh prefix should be able to uncover this incompatibility, so while it is silent, it is not the most silent thing there is. But the question remains: how do you think we should address the bug that bothers Akim, other than by this patch and a big warning in NEWS? Thanks, Ralf
Re: Do not create conditional installation directories
Allan Caffee wrote: On Sun, 15 Mar 2009, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Sun, Mar 15, 2009 at 11:43:03AM CET: I have a patch to let 'make install' not create installation directories in which no files will end up. This half-fixes a long-standing TODO item; so far, one had to work around this with conditionals and hacks in order to achieve it. However, there is a downside: this patch does not fix the TODO item for the 'installdirs' target (yet). Do you still think it's worthwhile to have, and ok if we leave installdirs to be fixed in a later version? There is another downside: up to now, one could use something like foo_DATA = to let $(DESTDIR)$(foodir) be created at installation time. This of course no longer works, and as such is a backward incompatibility. Was this ever a documented feature? I don't recall, but I know it is widely used and therefore will cause silent incompatibilities between the next automake version and its predecessors. To me personally, it's a severe functional regression. Ralf
