Summary:	ASTERISK-15157: [patch] Trunk won't build as cross-compilation
Reporter:	Philip Prindeville (pprindeville)	Labels:
Date Opened:	2009-11-17 17:27:29.000-0600	Date Closed:	2011-06-07 14:07:21
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/BuildSystem
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk.log ( 1) asterisk-trunk-cleandep.patch
Description:	I've applied the following patch not as a solution but as a diagnostic aid to try to figure out just when the necessary targets are being clobbered. From what I can tell, it's related to two issues (a) that "make clean" happens as a subshell and in subdirectories, which makes it hard to impose target prerequisites via '|'; (b) that the ordering of dependencies is suspect. The proof of these two assumptions being that the cleaning happens later than it should, sometimes even after the deleted files have been recreated.
Comments:	By: Philip Prindeville (pprindeville) 2009-11-17 17:38:45.000-0600 I've spent 6 hours on this trying to figure out the changes to how things build in 1.8 and the *clean* targets without luck. If whoever made those changes can work with me, I can reproduce this issue all the time. Not also that the above build didn't even use parallelism. By: Leif Madsen (lmadsen) 2009-11-18 09:55:50.000-0600 I originally dropped this from block to major because this is not blocking any releases, thus block is inappropriate. Major is also inappropriate here because it is an issue in a non-released version of Asterisk, thus I've set this to the correct severity of Minor. By: Philip Prindeville (pprindeville) 2009-11-18 14:38:36.000-0600 Also noticed that in main/Makefile, there's: SRC=$(wildcard *.c) which obviously doesn't take into account the dynamically generated source file main/version.c ... having this file be generated at the top-level makefile is problematic because then the rule to force its creation isn't visible to the sub-makefile that actually ends up using it. By: jmls (jmls) 2010-01-08 04:34:32.000-0600 does this just affect trunk, or 1.6.x svn branches as well ? By: Philip Prindeville (pprindeville) 2010-01-08 11:33:04.000-0600 Trunk only. By: Philip Prindeville (pprindeville) 2010-07-21 13:40:29 This bug no longer manifests itself, but I believe that's just the symptom going away.  It's not clear that the root-cause, which was found by inspection, has been fixed. By: Paul Belanger (pabelanger) 2010-07-21 16:06:30 Closing as reporter reports no longer an issue. By: Philip Prindeville (pprindeville) 2010-07-23 20:09:17 I didn't quite say it was no longer an issue.  I said the manifestation is no longer apparent.  That just might mean that whatever was triggering the bug has been suppressed. By: Paul Belanger (pabelanger) 2010-07-23 20:50:21 Aside from that, are you still having a problem? By: Philip Prindeville (pprindeville) 2010-07-23 21:40:32 No, as I said, everything seems to be working now.  No visible symptoms. By: Paul Belanger (pabelanger) 2010-07-23 21:51:30 Then we can close this issue, if there is no problem.