[pisa] Re: hipl braindeadness^w^w suggestions for tiny hipl

Diego Biurrun wrote:

Hi,


On Tue, Nov 03, 2009 at 05:34:50PM +0200, Miika Komu wrote:

Diego Biurrun wrote:


René asked me to write down some of the complaints I had about hipl.
Since Miika is directly listening here, I figured I could send them to
this list where they are archived and can be noticed and discussed.

It's quite a rant, so hang tight and don't take it too seriously, it's
much more fun to write rants than dry issue listings :)

[All the numbers I took from the midauth2 branch.]

So here goes:

** still using tla (OK, Miika is working on this)

 tla is a PITA and a resource hog.  Knowing tla is a dead skill and the
 tool is more of a hindrance than a help IMO.  Compared to what could
 be achieved with the alternatives, this is a net drain on developer
 productivity.

I am not confident on the tla branch imports done by git.


Why?
last time I synchronized to git, there was some strange output (M foo.c, M bar.c) that over flood my shell. I have been trying to reproduce the problem but no success yet. 

I have a git test repository and you can play with it if you want to:

git clone ssh:///var/www/infrahip/html/data/hipl/hipl-git
git clone http://hipl.hiit.fi/hipl/hipl-git

I'll wipe it clean at some point, so it's not for production use yet.
I agree with your individual suggestions but at the same time I'd like to avoid redundant work with TinyHIP. Anyway, I'll create some bugzilla items. 


** old unused branches

 Miika, what does your room look like?  Do you keep old but no longer
 used socks lying around? ;)
 All those old crufty branches are just confusing.  If they are unused,
 delete them.  They can be restored if necessary (but I bet it will
 never be necessary).
tla likes old socks, so the branches are cumbersome to remove. We have been also reusing the branches as much as possible. Is it actually common to delete branches in any projects? Think not, but I may be wrong. 

Most people are messies ;)


** most files are executable - WTF ??

 Source files should not be set executable.  Neither should anything
 except, surprise, executables.  This is incredibly lame, it looks as
 if it had been developed on a FAT32 drive from which proper Unix
 semantics could not be derived.  Sheesh, this is not some lame Windows
 project..

This is the umask syndrome...


Your point being?  It looks like the easy-to-fix syndrome to me...


** massive -I flag abuse

 The includes throughout hipl are handled in a terrible way.  Instead
 of using proper relative paths in the headers themselves, the compiler
 flags are bloated with literally dozens of -I flags.  This is ugly
 enough by itself, but as a bonus, if you want to use a hipl header
 outside of hipl, you have to recreate this mess...

I hope this can be solved with tinyhip's superior building system :)


No.  The build system will not make bad design decisions in the code
magically go away.  Why would you suddenly not need -I flags with a new
build system?

What superior, shiny-new build system do you intend to use?


cmake


** massive CFLAG abuse

 The compiler calls are bloated with faaaaaaaaaaaaaaaaaaaaaaaaar too
 many -D flags.  Such #defines should be in config.h.  Only definitions
 that are specific to certain files should be passed as -D flags.

It doesn't really bother my sleep at nights, but I tend to agree.


Why not fix it? :)


** horrible misuse of recursive automake

 My views on auto* are basically unprintable, but hipl takes the misuse
 of the autotools to another extreme.  They are used in a recursive
 fashion and there is recursion aplenty.  All Makefile.ams combined are
 more than 3000 lines long, hipl is about a million lines of code.  My
 raw Makefile for MPlayer is 1100 lines for about half a million lines
 of code, but I list one source/object file per line, so you can count
 it as about 600 lines for the purposes of this comparison.

Issue to be solved in TinyHIP?


Why wait for TinyHIP?


** gazillions of warnings

 The number of warnings just drows everything.  No wonder they don't
 get fixed, I mean, who could tell that file X now prints 101 instead
 of 100 warnings?  Many of them are harmless (but incredibly lame) like
 "unused this" and "redundant that", but I bet half of them are real
 bugs that nobody ever bothered to fix.
Issue to be solved in TinyHIP by enforcing -Wall or something even more scarier? 

Why wait for TinyHIP?


** rampant #ifdeffery

 Don't get me started, let's just say they are too many :)

Agree.


Well, try to get rid of them or at least try to mitigate further
increase in #ifdef abuse.


So much for this rant of mine.  You asked for it, you got it.  The worst
part is that I really did not dig deeply, on the contrary.  I shudder to
think of the horrors that a detailed investigation will uncover.  Also,
much of what I mentioned could be fixed very quickly, in minutes, hours,
days, but apparently nobody could ever be bothered so far...
I could write an essay as a response to this comment and list all the excuses but I'd rather not. Suffice to say that we should have a more strict compilation environment and some sort of automated test system. 

These are things that you can implement almost immediately.  Instruct
people to fix all those warnings in their code, add some appropriate
flags to your compilation commands...


My suggestion is to not only fix these things in tiny hipl, but fix them
in all of hipl.  At least don't spread the ugliness any further...
For me, TinyHIP will be the successor of HIPL and I'd like to concentrate at least my efforts on that rather spreading them on multiple places. 

I think the efforts are more or less orthogonal.  Perhaps I should
rather say that they pave the way from HIPL to TinyHIP.  Isn't the
purpose of TinyHIP to clean up all the mess from HIPL?  I think all the
points I listed should be on that to-do list :)

Diego

Other related posts: