[Asterisk-Dev] Re: Asterisk make clean and make looping?? (Possible solution)

[David Taylor]

Robert Webb" wrote:
> On Mon, 21 Nov 2005 14:52:05 -0600
>   "Kevin P. Fleming" <kpfleming at digium.com> wrote:
>   
>> Soner Tari wrote:
>>     
>>> It's been another 12 days, but this issue still exists 
>>> in newly released 
>>> 1.2 and in CVS-HEAD afaics (I've just checked out and 
>>> tried to compile). 
>>> Saul's workaround works for me, but it's not on CVS. Has 
>>> anybody 
>>> submitted a bug report to issue tracker for this yet?
>>>       
>> It is being worked on, and if I can get it resolved 
>> shortly it will be in the 1.2.1 release. The CVS system 
>> will be converted over to Subversion (SVN) very soon, so 
>> this problem will also likely go away then as well, as we 
>> won't need to make the version string include the date 
>> and time any longer.
>>     
> Kevin,
>
>    Sorry I did not follow up with you on this since 
> reporting. But it definitely is an issue with the compare 
> in the script. I was running mine under Debian Sarge when 
> the problem showed up. Not sure if it is the way compare 
> is returning its results or what.
>
>    I have just been really busy with an office move at 
> work and working on a Systems Analysis class for school.
>
> Robert Webb
>   
I'm sure you'll find that 'cmp' works perfectly.

The problem is that "the logic in the Makefile is faulty" (ref.. my post 
on Nov 8th).

The looping occurs as follows:

1.  Each time make is run, because version.h is FORCE'd, the commands 
associated with it are run.

1a.  Now 'cmp' attempts to ensure that if the 'version number' has not 
changed then version.h will not be updated.  And this works in the cases 
where the version number is not dependent on the time & date.

1b.  So the first error in the logic occurs here iff you have a CVS/Tag 
file at the top of your build tree.  In this case the version number 
includes the time and date down to the second!  (eg. 
"CVS-Nv1-2-0-11/22/05-17:38:10")  And so each time these commands are 
run for a particular CVS-tagged version of the sources the 'version 
number' changes!!

2.  Because '.depend' depends on version.h, this gets rebuilt each time 
version.h is updated.

3.  And the Makefile depends on '.depend' ... because it is 'include'd 
in the makefile.  And this of course causes the makefile to be re-read 
and all dependency processing to be restarted ... taking us back to step 
1 and leading to the looping behaviour we see.


So, what's the fix?  Well Kevin seems to believe that the move to 
Subversion will make a difference, although there doesn't seem to be any 
good reason why a time&date needs to be included in builds based on a 
particular CVS-Tag.  And why not include the time&date in CVS-HEAD based 
versions where it's probably even more relevant?  It really looks like 
the question of version numbering needs some thought.  In fact, if you 
look at the current logic you will find that both ASTERISKVERSION and 
ASTERISKVERSIONNUM produce some 'interesting' results depending on your 
particular build environment.  For instance, ASTERISKVERSIONNUM will 
*always* be either 999999 if you have a CVS file/directory or 000000 if 
you don't.  In fact, it seems to be the intention that the version 
number be extracted from info in the '.version' file if it exists 
although this can never work as it stands today (at least in version 
CVS-Nv1-2-0).

Now, I could (and would) rewrite the Makefile, but the intent is not clear.


For those interested in understanding how the looping occurs please have 
a look at the following cut-down version of the Makefile.  Try also 
running it using the '-d' flag to see what's really going on.

    .EXPORT_ALL_VARIABLES:

    ASTERISKVERSION=$(shell echo "CVS-`sed 's/^T//g' CVS/Tag`-`date 
+"%D-%T"`")

    ifneq ($(wildcard .depend),)
      include .depend
    endif

    .depend: include/asterisk/version.h
        build_tools/mkdep $(CFLAGS) $(wildcard *.c)

    include/asterisk/version.h: FORCE
        build_tools/make_version_h > $@.tmp
        cat $@.tmp
        if cmp -s $@.tmp $@ ; then echo; else \
            mv $@.tmp $@ ; \
        fi
        rm -f $@.tmp

    FORCE:

Try any one of the following:
  1.  Remove the date&time component [-`date +"%D-%T"`] from the 
definition of ASTERISKVERSION.
  2.  Remove the "include .depend" line
  3.  Remove the dependency of version.h on FORCE

Any of these should make it 'work' ... or at least stop it looping.

So, what is the final answer?  Well it probably depends on what you are 
trying to achieve.  And if that means a clean and minimal build under 
all circumstances - ie. whether built from a tar ball, from sources 
pulled from CVS (ie. from HEAD or a specific tagged version), or other - 
then it's probably a job for someone who has a far more intimate 
knowledge than I of just how all the sources are glued together.

As I have said before, it looks to me like the main culprit is the 
inclusion of the date&time in the version coupled with the the 
not-so-obvious dependency of the Makefile itself on '.depend'.

I recommend caution for those who want to simply remove the FORCE'ing of 
version.h.  Without this your dependencies (ie. in '.depend') will 
probably end up out-of-date.  In fact, '.depend' should probably depend 
on *all* '.c' and '.h' files and use similar 'cmp'-based logic to that 
in the commands for version.h to ensure that '.depend' is (a) checked 
when any source file is changed but (b) not actually updated unless 
there has actually been a change in the resulting dependencies.

And is removing the date&time from the version the whole fix?  I think 
not.  It looks to me like there are a number of fundamental dependency 
issues that really need to be resolved.  And these probably need to be 
resolved by people very familiar with the code base.  Then those 
occasional coders who fly in with a particular problem can get stuck 
into it straight away; contribute their solution; and then move on ... 
without having to fight the fundamental flaws in the build process.

Cheers,
David.  [Jumps off soap box and crawls back into his cozy little hole :-]