AW: AW: [Xbox-linux] cvs cromwell build

[Lehner F. <fr...@ca...>]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

again, i tell you.

keep quite.

3 people of the xbox linux core team said NO
and we have our reasons.

there are a lot:
1 - you do not know what is future comming
2 - never touch a runnign system
(are your changes valiated on redhat, debinan, different gcc versions
and cygwin compilers ?)
also you have to verify it on all versions of the xbox too ! i had
this problem in the 2.24 release.
and as result, it crashed on 1.0 boxes :-(

3 - are your changes stabile ? no- sure not
4 - why is linux kernel compiling the same way ?
5 - the usb stack is portet 1:1 from the 2.5.73 linux kernel.
i see no need for changes, that "YOUR" compile system can handle it.
or do you think, the guys who wrote the linux usb stack need help in
coding there makefile?

so
if you are soo good, go to linux kernel, you find 100% the same there
maybe you can try to "make" there, but they will laugh about it as we
do here too.
sorry, it was sure a good "idea" of doing it and sure a lot of work
to get it running.
but as michael already told you:
as you have 0 idea about the compleate thing works, you are doing
crazy things.
and yes, i have read your changes, i even applied the patch.
and it is horror.

i have seen more as one time, that cromwell crashes without coding
mistake.
and i spent weeks in searching with the debugger (IDA-pro) for the
sequences and look if the compiler did it the way i wantet.
and usually the compiler makes the mistake.
so i have to write it different in C to let the compiler not kill the
things.

and the ANSWER IS NO !
NO
NO
NO

and if you write another mail, telling your change are "soo good"
i will write an not very friendly email then.

if you want faster re-compiling, use ccache. (maybe kill -pipe too)
this is working perfect, and i am using it the whole day.
http://ccache.samba.org/
even gcc is recommending this solution .

YEAH, samba compiling the same way, maybe you try to tell them how to
write the makefiles.

there are reasons, why these things are existing and this way of
compiling exists.
also this way of compiling is recommended on gcc manual. specially
when wrting an OS and 100% when you write a BIOS !
look into the linuxbios pages, and you find mass of "compile horror
problems"
the same with Etherboot.

boy, this is a bios, and runns multiple programms.
all programms are linked with linker-scripts.
in theory, i could merge all linkerscripts into one ! .ld script too.
this should work.
but DOES NOT WORK stabile.
"answer from linker script people: "boy, this is a linkerscript, try
to use is like a linkerscript and not like a compleate programm" "

also one of the features why this is so beautiful (make process) that
you can force single files compile for multiple destinations (like
the sha1.c) and force only special directory's compile with other or
additional Compile-flags.
very simple, and with no mega-hack in the main file.
this is the way how it should be.

and again.

the "compile" errors you describe are typically.
one time it works, the other it fails.
if you read (you sure not done)
the "unknown mysterious things" in gcc developerlist, you sure find
out very fast why this is not good.
and i am not willing to teach now a lesson about how to use a
compiler.
example:
gcc 3.3 and no picture:
it is 100% identified that this is compile problem, the section is
already found in IDA (this is funny isn't it)
and the mistake is found !
the same happens when compiling with -O3 (even on 2.95), it is
definitiv a compiler optimazion problem. (i spoke with gcc too)
you see this very clear in IDA when you disasemble it again.
But i do not care about the video anymore, as the compleate video lib
is written new, as we are implementing focus support at this time.
and there will be a 100% code swap.

xbeboot.S not using compile options ? -> boy look into
you see a need for a compile option there ? -> the compleate thing is
100% ASM.

so shut up.
we do not need to be "urged"
as the thing is fuck.

yesterday, we had a discucsion about it: people: ed, me, mist
mist was neutral, he does not know cromwell too (only from using)
but not from the coding side, he then recognized, that this is really
important.

and the answer is and was NO.
really sorry, it is sure a good work and you spent a lot of work into
, really.

but one of this problem here is, that people are making a cvs co
cromwell here,
compile the bios
and flash it to the onboard bios then.
IF this fails, are you then buying them a new xbox ? i am sure , this
compile way is soo safe, that nothing can happen.
but are you so 100% sure about your's too ?
I know a lot of people doing this way.

and again:
- -never change a running system.

if you want to make something "useful", take a 2.5.73 or so kernel.
and look, why the "USB bug" happens there too !!!
the linux people are searching it but not found yet.

if you are interested in doing something productive, tell me.
there are mass of sections inside cromwell, which have to be
rewritten or recoded.
or new implemented.
examples:
compile grub with riserFS and Ext3 support (both)
- --> crash
this are much more important things to investigate, instead of
spening work about something with works 100% stabile.
(even if it is slow, as it does not matter for a normal person as
they do not recompile it. and if you are a developer -> ccache )


franz


- -----Ursprungliche Nachricht-----
Von: xbo...@li...
[mailto:xbo...@li...]Im Auftrag von
Oskar Liljeblad
Gesendet: Donnerstag, 30. Oktober 2003 06:49
An: xbo...@li...
Betreff: Re: AW: [Xbox-linux] cvs cromwell build


On Wednesday, October 29, 2003 at 23:12, Michael Steil wrote:
> The build system of Cromwell is a feature, not a bug. It is meant
> that  way. It is true that the dependencies don't work as in other
> projects,  but Cromwell is unlike other projects. Cromwell consists
> of six systems  that have been linked together.
> GCC issues make it close to impossible to implement proper
> makefiles.  There are many issues, like the order of linkage, GCC
> ignoring changed  .h files etc.

Well, the generated dependencies say that whenever header file .h is
changed, every .c file that includes is also changed. This is
optional
behavior, and can be removed from the makefile entirely. However, I
am
convinced it is the correct behavior.

The new Makefile addresses the following problems:

some files were built incorrectly
  Implicit make rules were used, some files were built without CFLAGS
  (xbeboot.S etc)

old makefile always did clean on build
  This makes the makefile broken. Better of with a build script
then...

new makefile has correct & complete dependencies, automaticly
generated
  If you change one file, expect every other file that depends on it
  to be rebuilt. Also, image compression using imagebld is done
  separately for each target. It is possible to use 'make
default.xbe'
  to just build that file.

builds object and binary files into same dir as code
  This could be argued, but it is cleaner this way in my opinion.
Otherwise
  all could should be build a in a specific directory (not objs, bin,
xbe,
  image etc).

minor code corrections -Wall -Werror
  This was necessary to build with the above options.

proper separation of host tool compilation (imagebld) and other code
  Compiling imagebld requires different flags (not
- -march=pentium/-mcpu=pentium)
  since your host OS may not be pentium.

single toplevel makefile
  What's the point of makefiles in subdirs if they can't be used by
running
  make in subdir?

I urge you, Franz and Ed, and everyone else interested to take a look
at the
Makefile again, and explain to me what's wrong. Of course I'd respect
whatever
decision, but not if it is based on lose grounds and only if it's
explained...
We all code here to make stuff better, don't we? 

Regards,

Oskar Liljeblad (os...@os...)


- -------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Xbox-linux-devel mailing list
Xbo...@li...
https://lists.sourceforge.net/lists/listinfo/xbox-linux-devel

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBP6DdDBbHVw21GxJvEQLTZgCfX2Le9ha6m/7e3bMMLPOM7KYCd9wAn1O4
Wg32xo75J8OLqSjhhKaYEQus
=cO0e
-----END PGP SIGNATURE-----