[U-Boot] Fix for a build ?

[Wolfgang Denk]

Dear Sylvain Lamontagne,

In message <s2j3e45db431005031502zb199821fndee7e8f220853489 at mail.gmail.com> you wrote:
>
> > Heh. So what do you want? A solution, but no changes?
>
> I was asking in case someone remembered and could have been an easy fix.
> Something like:
> Yes, Sylvain If I remember there was a race condition with MakefileX
> in Y specially on an SMP machine.
> That would have been a perfectly correct answer.

We have about 650 Makefiles in the current U-Boot source tree; the top
level Makefile alone has seen 371 commits since v1.3.4, including
major reworks like changes to the directory structure, architecture
renames, etc. There have been a number of plain bug fixes to the U-Boot
build system, and there have been a number of work-arounds for broken
tool chains like the broken GNU make 3.80 or for some broken ARM
compilers.

In total there must be way over 1000 commits to Makefiles, plus
several hundred to config.mk and other make related files.

I am not in a position to remember each and every of these changes, or
their potential impact on building in SMP configurations.

> That was absolutely not what I was asking for ... I did not want
> anybody of you to fix this for me. I was asking for pointers and it
> was a quick question that should have get a quick answer, nothing
> more.

I gave you  quick answer: use git bisect to find out which commit
makes a difference for your build system. Of course this requires that
you have some build target that is supported in mainline, and that
shows the same problem like your out-of-tree port.

> You may have never been in this situation, but I work for a company
> that is big enough to not let me change something that work fine only
> for some failure from time to time related to a race condition on a
> new automated build server.

I have. More than once. And of course we have customers in such
situations, too.

> I did try to update U-Boot in the past few month but I always end-up
> with problem related to variables that changes names (CFG vs CONFIG)
> or to bizarre memory config created by my predecessor  that make the
> new version unworkable. I am not an electronician and there is still

As Mike already pointed out this is a well known problem, and it is
important that you understand that it's a completely self-made
purgatory. U-Boot develops continuously and quickly, so any
out-of-tree port is obsolete as soon as you release it, and
maintaining it over more than a few months costs way more effort than
pushing your changes upstream into the mainline repositories.

You can now waste efforts on trying to back-port fix after fix from
mainline to your old code, or you can invest the effort in updating
your code base and pushing it upstream. This is your (or your
manager's) decision. We don't actually care about this, but it seems
only fair to mention that from our experience the one-time effort to
push things upstream is smaller than the repeating costs of
maintaining an out-of-tree port.

> aspect of embedded development that I don't yet understand. I have an
> IT degree and I'm currently learning embedded "in the field" since my
> predecessor was laid off. If giving chance to people is not in your
> nature, then I'm sorry to have been taking your time.
> Make it easy to upgrade and people may then upgrade more often. The

You seem to fail to understand how a free software project like U-Boot
works. U-Boot is very easy to upgrade - we take great care not to
break support for any of the supported boards, and we accept even
exotic boards and include these into the mainline tree, even if there
is most likely no other user ever.

So if you want to be able to upgrade easily just make sure your code
is part of the mainline distribution.

By not pushing your code upstream you may save a certain amount of
effort, but you also miss the chance of getting a free code review by
a number of highly qualified experts that may improve the quality of
your code considerably, and you accept that you will have to spend
maintenance efforts all yourself.

This is *your* choice.  It is nothing we can do for you, or refrain
from doing for you.

> Linux kernel 2.4 is still supported in some way for people that have
> very old hardware that work only with it, so why wouldn't it be
> legitimate to keep a tested version of U-Boot on a running product
> only because it's 2 year old ?

U-Boot takes really, really lots of efforts to keep even ancient
boards working - in mainline, that it.

The responsibility for any out-of-tree port like yours is completely
in your own hands.

> Anyway thx for answering even if the answer was a bit rude...

I did not intend to be rude, but I have to admit that your attitude
is not exactly in line how community projects like this work.

I don't have the time to answer requests like yours in long prosa -
the build system is a pretty complex issue and there are tons of
factors that have impact. I already mentioned tool chain issues like
broken ARM compilers or things like the white-space madness in GNU
make 3.80, but there are tons more. Is your source directory mounted
over NFS? Depending on the NFS version you may see problems (like
https://bugzilla.redhat.com/show_bug.cgi?id=530625 resp.
http://bugs.gentoo.org/show_bug.cgi?id=289022). Are you using any
sort of caching? Fscache has it's onw collection of bugs, ccache has
some known issues, and so on and on. You did not reveal any
information about you build environment, so you should not expect too
much useful feedback either. Maybe you want to read
http://catb.org/esr/faqs/smart-questions.html

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Computers are not intelligent.  They only think they are.