Code consolidation

George Boudreau georgeb at
Mon Aug 7 10:52:03 PDT 2006

Dan Nicholson wrote:
> On 8/5/06, George Boudreau <georgeb at> wrote:
>>    If you wander through the file, you notice many instances of 'near'
>> duplication. I had fallen into the bad habit of optimizing the bash
>> scripts and not applying the same diligence to the final output. I am
>> suggesting, for jhalfs-2.0, that some time be spent on analyzing the
>> Makefile with an eye to consolidating some of these 'near' duplicate
>> functions into the makefile-functions file.
> This is definitely what I had in mind. The Makefile is a jumble, so if
> any issue crops up, you basically have to hand hack it. IMO, there
> should be more use of variables in the Makefile. I'm not make expert,
> but it shouldn't be too hard to cut down the redundancy considerably.
> I see things like this:
>        @( time { su - lfs -c "source /home/lfs/.bashrc &&
> /mnt/lfs/jhalfs/lfs-commands/chapter05/028-binutils-pass1"
>>> logs/028-binutils-pass1 2>&1 ; } ) 2>>logs/028-binutils-pass1 && \
>        echo -e "\nKB: `du -skx --exclude=jhalfs $(MOUNT_PT)`\n"
>>> logs/028-binutils-pass1
> And immediately, I think this could be simplified considerably.
> BASEDIR = /mnt/lfs/jhalfs
> CMDSDIR = $(BASEDIR)/lfs-commands
> SU_LUSER = su - $(LUSER) -c
> PRT_DU = echo -e "\nKB: `du -skx --exclude=jhalfs $(MOUNT_PT)`\n"
> LUSER_HOME = /home/$(LUSER)
> I also believe that the current target is $^ in make. I stole that
> from the Mozilla Makefiles.
> That would reduce the above to something like
>    @( time { $(SU_LUSER) "source $(LUSER_HOME)/.bashrc &&
>        $(CMDSDIR)/chapter05/$^" >> logs/$^ 2>&1; } ) 2 >> logs/$^ &&
>        $(PRT_DU) >> logs/$^
> Just a quick hack. I'm sure it could be better.

   I like the ideas you put forth, it does compress the cmd string 
nicely. I will spend the next week working on code compression in both 
the output Makefile as well as common-functions.

>>    Although the majority of the users will never look at Makefile and
>> this effort will not produce one iota of speed improvement, I believe
>> readability is a precursor to maintainability.
> Absolutely. Making the code more readable is paramount to getting
> people to understand it. This also allows for people to easily change
> what's happening in special situations.
   Manuel, I do not think we need an 'official' announcement on the 
feature freeze as there are very little interest/suggestions coming from 
the mailing list. If we receive a request we could make a general 
statement about the freeze at that point.

> -- 
> Dan

  A general note.. I wrote a generator for BLFS. It creates a 
fully populated config file from the packages files. I don't know if 
this will be useful for BLFS and I may keep it as a testing tool. (I am 
still looking at BLFS, Manuel :-) )

More information about the alfs-discuss mailing list