[U-Boot-Users] Build system improvements?

Being used to the Linux kernel 2.5 build system, the build system for Das U-Boot looks like an area for improvements.
What features are most seeked among the u-boot developers?
I will not promise, but I may take a stamp on it.
Being inspired from the Linux kernel I have the following things in mind: (no particular order) - Less verbose output - Dependency generation including dependency on CONFIG symbols - Kernel config tool
Sam

In message 20030609111148.GA10440@mars.ravnborg.org you wrote:
Being used to the Linux kernel 2.5 build system, the build system for Das U-Boot looks like an area for improvements.
What features are most seeked among the u-boot developers?
I will not promise, but I may take a stamp on it.
This has been discussed at length before. See the mailing list archive, for example the thread "Linux Kernel Config 1.2 for u-boot?" started by Holger Schurig on Tue, 5 Nov 2002.
Being inspired from the Linux kernel I have the following things in mind: (no particular order)
- Less verbose output
Less verbose output? Please don't.
If you want a semi-silent build just use "MAKEALL target". For all other cases I insist on being able to see what's going on. I hate "silent" build procedures where you have to waste your time to figure out what's going wrong and where and why.
- Dependency generation including dependency on CONFIG symbols
- Kernel config tool
See previous discussion.
First thing you should do is to define _why_ you want to do this. Do you want to make it easier to port U-Boot to a new board? Is yout target group the programmer who just starts his first port, or the expert who is doing this for the umpteenth time?
Best regards,
Wolfgang Denk

On Mon, Jun 09, 2003 at 01:51:50PM +0200, Wolfgang Denk wrote:
In message 20030609111148.GA10440@mars.ravnborg.org you wrote:
Being used to the Linux kernel 2.5 build system, the build system for Das U-Boot looks like an area for improvements.
What features are most seeked among the u-boot developers?
I will not promise, but I may take a stamp on it.
This has been discussed at length before. See the mailing list archive, for example the thread "Linux Kernel Config 1.2 for u-boot?" started by Holger Schurig on Tue, 5 Nov 2002.
I only went back to January this year. I will take a look.
Being inspired from the Linux kernel I have the following things in mind: (no particular order)
- Less verbose output
Less verbose output? Please don't.
Why bother people with a lot of noise when less can do it in 99% of the cases. The verbose variant is needed for sure - agree 100%. But I do not see why it shall be the default choice. Then a build where nothing is actually build should give minimum output. Why should I be bothered with useless information about what directory make visited for example. Much better to compile everything from the same root. Error messages is still OK, and you do not have to find out which of the files with the same name was the culprint. After a screen full of warnings where you lost the make info.
First thing you should do is to define _why_ you want to do this. Do you want to make it easier to port U-Boot to a new board? Is yout target group the programmer who just starts his first port, or the expert who is doing this for the umpteenth time?
My main focus is to make life easier for the newcomers, and give a bit value to the experts. No-one should suffer, especially not the daily users.
I will take a look at the above mentioned mail thread - and then mail my initial conclusins. Earlist next week - being busy...
Sam

On Mon, Jun 09, 2003 at 01:11:48PM +0200, Sam Ravnborg wrote:
Being used to the Linux kernel 2.5 build system, the build system for Das U-Boot looks like an area for improvements.
I've already done a kconfig port to u-boot some time ago, please have a look at our web page if you are interested. Unfortunately Wolfgang doesn't want to have it in u-boot, so I have not followed this path further.
Robert

On Mon, Jun 09, 2003 at 09:45:25PM +0200, Robert Schwebel wrote:
On Mon, Jun 09, 2003 at 01:11:48PM +0200, Sam Ravnborg wrote:
Being used to the Linux kernel 2.5 build system, the build system for Das U-Boot looks like an area for improvements.
I've already done a kconfig port to u-boot some time ago, please have a look at our web page if you are interested. Unfortunately Wolfgang doesn't want to have it in u-boot, so I have not followed this path further.
I will take a look, thanks. But if the conclusion is that it is waste of time then no more than that :-)
Sam

In message 20030609194525.GB9379@pengutronix.de you wrote:
I've already done a kconfig port to u-boot some time ago, please have a look at our web page if you are interested. Unfortunately Wolfgang doesn't want to have it in u-boot, so I have not followed this path further.
URL please? I can see the description for "LKC support for U-Boot" but no link. Is this "u-boot-config-1.diff" ? All I get for this is:
Not Found The requested URL /software/csb226/u-boot-config-1.diff was not found on this server.
Best regards,
Wolfgang Denk

On Mon, Jun 09, 2003 at 10:43:02PM +0200, Wolfgang Denk wrote:
URL please? I can see the description for "LKC support for U-Boot" but no link. Is this "u-boot-config-1.diff" ? All I get for this is:
Not Found The requested URL /software/csb226/u-boot-config-1.diff was not found on this server.
Hmm, seems to need some maintainance. But I have the tree available locally and could port it to the current state if needed. The question is: would it be a desirable feature to have a configuration frontend? Until now I thought your position was not, so I didn't spend more time.
Robert

On Mon, Jun 09, 2003 at 11:01:00PM +0200, Robert Schwebel wrote:
Hmm, seems to need some maintainance.
I've fixed the link now. Note that it is from the era when kconfig was not yet merged with the kernel, so some things might have improved in the meantime. But porting it up should not be a big deal, I've done it several times for PTXdist recently.
Robert

In message 20030609214545.GF9379@pengutronix.de you wrote:
I've fixed the link now. Note that it is from the era when kconfig was not yet merged with the kernel, so some things might have improved in the meantime. But porting it up should not be a big deal, I've done it several times for PTXdist recently.
Doesn't work for me:
-> make xconfig make -C tools/lkc-1.2 libkconfig.so make[1]: Entering directory `/tmp/u-boot/tools/lkc-1.2' gcc -O2 -Wall -g -fPIC -c zconf.tab.c -o zconf.tab.o gcc -shared zconf.tab.o -o libkconfig.so make[1]: Leaving directory `/tmp/u-boot/tools/lkc-1.2' make -C tools/lkc-1.2 qconf make[1]: Entering directory `/tmp/u-boot/tools/lkc-1.2' g++ -O2 -Wall -g -fPIC -I/usr/lib/qt3-gcc3.2/include -c qconf.cc -o qconf.o In file included from qconf.cc:25: qconf.moc:29: no `void ConfigList::initMetaObject()' member function declared in class `ConfigList' qconf.moc: In member function `void ConfigList::initMetaObject()': qconf.moc:33: `badSuperclassWarning' undeclared (first use this function) qconf.moc:33: (Each undeclared identifier is reported only once for each function it appears in.) In file included from qconf.cc:25: qconf.moc: At global scope: qconf.moc:40: prototype for `QString ConfigList::tr(const char*)' does not match any in class `ConfigList' qconf.h:20: candidate is: static QString ConfigList::tr(const char*, const char* = 0) In file included from qconf.cc:25: qconf.moc: In static member function `static QMetaObject* ConfigList::staticMetaObject()': qconf.moc:78: no method `QMetaObject::new_metadata' qconf.moc:79: no method `QMetaObject::new_metaaccess' qconf.moc:81: `struct QMetaData' has no member named `ptr' qconf.moc:81: `QMember' undeclared (first use this function) qconf.moc:81: parse error before `;' token qconf.moc:84: `struct QMetaData' has no member named `ptr' qconf.moc:84: parse error before `;' token qconf.moc:87: `struct QMetaData' has no member named `ptr' qconf.moc:87: parse error before `;' token qconf.moc:90: `struct QMetaData' has no member named `ptr' qconf.moc:90: parse error before `;' token qconf.moc:93: `struct QMetaData' has no member named `ptr' qconf.moc:93: parse error before `;' token qconf.moc:111: no method `QMetaObject::new_metadata' qconf.moc:113: `struct QMetaData' has no member named `ptr' qconf.moc:113: parse error before `;' token qconf.moc:115: `struct QMetaData' has no member named `ptr' qconf.moc:115: parse error before `;' token qconf.moc:117: `struct QMetaData' has no member named `ptr' qconf.moc:117: parse error before `;' token qconf.moc:119: `struct QMetaData' has no member named `ptr' qconf.moc:119: parse error before `;' token qconf.moc:128: no matching function for call to `QMetaObject::new_metaobject( const char[11], const char[10], QMetaData*&, int, QMetaData*&, int, int, int, int, int, int, int)' /usr/lib/qt3-gcc3.2/include/qmetaobject.h:199: candidates are: static QMetaObject* QMetaObject::new_metaobject(const char*, QMetaObject*, const QMetaData*, int, const QMetaData*, int, const QMetaProperty*, int, const QMetaEnum*, int, const QClassInfo*, int) qconf.moc:129: no matching function for call to `QMetaObject::set_slot_access( QMetaData::Access*&)' qconf.moc:69: warning: unused variable `void (QObject::*ov1_0)(menu*)' qconf.moc:71: warning: unused variable `void (QObject::*ov1_1)(ConfigItem*)' qconf.moc:73: warning: unused variable `void (QObject::*ov1_2)(ConfigItem*, tristate)' qconf.moc:75: warning: unused variable `void (QObject::*ov1_3)(ConfigItem*)' qconf.moc:77: warning: unused variable `void (QObject::*ov1_4)()' qconf.moc:104: warning: unused variable `void (QObject::*ov2_0)(menu*)' qconf.moc:106: warning: unused variable `void (QObject::*ov2_1)()' qconf.moc:108: warning: unused variable `void (QObject::*ov2_2)(ConfigItem*)' qconf.moc:110: warning: unused variable `void (QObject::*ov2_3)()' In file included from qconf.cc:25: qconf.moc: In member function `void ConfigList::menuSelected(menu*)': qconf.moc:161: invalid type argument of `unary *' qconf.moc:169: invalid type argument of `unary *' In file included from qconf.cc:25: qconf.moc: In member function `void ConfigList::parentSelected()': qconf.moc:180: invalid conversion from `const char*' to `int' qconf.moc:180: initializing argument 1 of `void QObject::activate_signal(int) ' qconf.moc: In member function `void ConfigList::symbolChanged(ConfigItem*)': qconf.moc:206: invalid type argument of `unary *' qconf.moc:214: invalid type argument of `unary *' In file included from qconf.cc:25: qconf.moc: In member function `void ConfigList::gotFocus()': qconf.moc:225: invalid conversion from `const char*' to `int' qconf.moc:225: initializing argument 1 of `void QObject::activate_signal(int) ' qconf.moc: At global scope: qconf.moc:237: no `void ConfigLineEdit::initMetaObject()' member function declared in class `ConfigLineEdit' In file included from qconf.cc:25: qconf.moc:248: prototype for `QString ConfigLineEdit::tr(const char*)' does not match any in class `ConfigLineEdit' qconf.h:155: candidate is: static QString ConfigLineEdit::tr(const char*, const char* = 0) In file included from qconf.cc:25: qconf.moc: In static member function `static QMetaObject* ConfigLineEdit::staticMetaObject()': qconf.moc:271: no method `QMetaObject::new_metadata' qconf.moc:273: `struct QMetaData' has no member named `ptr' qconf.moc:273: parse error before `;' token qconf.moc:282: no matching function for call to `QMetaObject::new_metaobject( const char[15], const char[10], int, int, QMetaData*&, int, int, int, int, int, int, int)' /usr/lib/qt3-gcc3.2/include/qmetaobject.h:199: candidates are: static QMetaObject* QMetaObject::new_metaobject(const char*, QMetaObject*, const QMetaData*, int, const QMetaData*, int, const QMetaProperty*, int, const QMetaEnum*, int, const QClassInfo*, int) qconf.moc:283: no matching function for call to `QMetaObject::set_slot_access( QMetaData::Access*&)' qconf.moc:270: warning: unused variable `void (QObject::*ov2_0)(ConfigItem*)' qconf.moc: In member function `void ConfigLineEdit::lineChanged(ConfigItem*)': qconf.moc:312: invalid type argument of `unary *' qconf.moc:320: invalid type argument of `unary *' In file included from qconf.cc:25: qconf.moc: At global scope: qconf.moc:337: no `void ConfigView::initMetaObject()' member function declared in class `ConfigView' In file included from qconf.cc:25: qconf.moc:348: prototype for `QString ConfigView::tr(const char*)' does not match any in class `ConfigView' qconf.h:171: candidate is: static QString ConfigView::tr(const char*, const char* = 0) In file included from qconf.cc:25: qconf.moc: In static member function `static QMetaObject* ConfigView::staticMetaObject()': qconf.moc:426: no method `QMetaObject::new_metadata' qconf.moc:427: no method `QMetaObject::new_metaaccess' qconf.moc:429: `struct QMetaData' has no member named `ptr' qconf.moc:429: parse error before `;' token qconf.moc:432: `struct QMetaData' has no member named `ptr' qconf.moc:432: parse error before `;' token qconf.moc:435: `struct QMetaData' has no member named `ptr' qconf.moc:435: parse error before `;' token qconf.moc:438: `struct QMetaData' has no member named `ptr' qconf.moc:438: parse error before `;' token qconf.moc:441: `struct QMetaData' has no member named `ptr' qconf.moc:441: parse error before `;' token qconf.moc:444: `struct QMetaData' has no member named `ptr' qconf.moc:444: parse error before `;' token qconf.moc:447: `struct QMetaData' has no member named `ptr' qconf.moc:447: parse error before `;' token qconf.moc:450: `struct QMetaData' has no member named `ptr' qconf.moc:450: parse error before `;' token qconf.moc:453: `struct QMetaData' has no member named `ptr' qconf.moc:453: parse error before `;' token qconf.moc:456: `struct QMetaData' has no member named `ptr' qconf.moc:456: parse error before `;' token qconf.moc:459: `struct QMetaData' has no member named `ptr' qconf.moc:459: parse error before `;' token qconf.moc:462: `struct QMetaData' has no member named `ptr' qconf.moc:462: parse error before `;' token qconf.moc:465: `struct QMetaData' has no member named `ptr' qconf.moc:465: parse error before `;' token qconf.moc:468: `struct QMetaData' has no member named `ptr' qconf.moc:468: parse error before `;' token qconf.moc:471: `struct QMetaData' has no member named `ptr' qconf.moc:471: parse error before `;' token qconf.moc:481: no matching function for call to `QMetaObject::new_metaobject( const char[11], const char[12], QMetaData*&, int, int, int, int, int, int, int, int, int)' /usr/lib/qt3-gcc3.2/include/qmetaobject.h:199: candidates are: static QMetaObject* QMetaObject::new_metaobject(const char*, QMetaObject*, const QMetaData*, int, const QMetaData*, int, const QMetaProperty*, int, const QMetaEnum*, int, const QClassInfo*, int) qconf.moc:482: no matching function for call to `QMetaObject::set_slot_access( QMetaData::Access*&)' qconf.moc:397: warning: unused variable `void (QObject::*ov1_0)(QListViewItem*) ' qconf.moc:399: warning: unused variable `void (QObject::*ov1_1)(menu*)' qconf.moc:401: warning: unused variable `void (QObject::*ov1_2)()' qconf.moc:403: warning: unused variable `void (QObject::*ov1_3)()' qconf.moc:405: warning: unused variable `void (QObject::*ov1_4)()' qconf.moc:407: warning: unused variable `void (QObject::*ov1_5)()' qconf.moc:409: warning: unused variable `void (QObject::*ov1_6)()' qconf.moc:411: warning: unused variable `void (QObject::*ov1_7)()' qconf.moc:413: warning: unused variable `void (QObject::*ov1_8)()' qconf.moc:415: warning: unused variable `void (QObject::*ov1_9)()' qconf.moc:417: warning: unused variable `void (QObject::*ov1_10)(bool)' qconf.moc:419: warning: unused variable `void (QObject::*ov1_11)(bool)' qconf.moc:421: warning: unused variable `void (QObject::*ov1_12)(bool)' qconf.moc:423: warning: unused variable `void (QObject::*ov1_13)(bool)' qconf.moc:425: warning: unused variable `void (QObject::*ov1_14)(bool)' make[1]: *** [qconf.o] Error 1 make[1]: Leaving directory `/tmp/u-boot/tools/lkc-1.2' make: *** [tools/lkc-1.2/qconf] Error 2
"make menuconfig" works to some extend, but it's impossible to select any board default configuration?
How can I - for example - use this to build U-Boot for the TQM860L board?
Best regards,
Wolfgang Denk

On Tue, Jun 10, 2003 at 12:13:18AM +0200, Wolfgang Denk wrote:
Doesn't work for me:
Hmm, that's what I supposed. It should be ported up to a recent version. Unfortunately I don't have that much time at the moment to try it out. You are right that a test case would surely be a better base for further discussion.
Robert

In message 20030609210100.GD9379@pengutronix.de you wrote:
Hmm, seems to need some maintainance. But I have the tree available locally and could port it to the current state if needed. The question is: would it be a desirable feature to have a configuration frontend? Until now I thought your position was not, so I didn't spend more time.
Please re-read the thread. I had (and have) some concerns, but to have an opinion I have to see something first.
Best regards,
Wolfgang Denk
participants (4)
-
Robert Schwebel
-
Robert Schwebel
-
Sam Ravnborg
-
Wolfgang Denk