Dan Nicholson wrote:
> On 8/5/06, George Boudreau <georgeb linuxfromscratch.org> 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&q
uot;
>>> 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 Config.in 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  )
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page
|
> A general note.. I wrote a Config.in 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