This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Rob and All, It sounds to me like you're problem with crosstool-ng is that it isn't firmware-linux and you're now using the crosstool-ng mailing list to promote your own design and tool. I've tried to read through you're extreamly long comparison and justification of firmware linux and I think most of your points boil down to personal preference and believes more than actual valid design arguments agaist crosstool-ng. - These tools are obviously very different designs and doesn't overlap. In short, my take on crosstool-ng vs. firmware linux is that one is well contained, well done, works and is usefull - while the other just isn't ready for primetime, looks like an interesting research project and is a great proof of concept. Where this not supposed to be a crosstool-ng design discussion thread instead of a >> who can write the longest emails competition << ? Anyway, just my 0.02$ Best regards, Stefan Hallas Andersen Cisco Systems Inc. > -----Original Message----- > From: crossgcc-owner@sourceware.org on behalf of Yann E. MORIN > Sent: Mon 4/6/2009 3:12 PM > To: crossgcc@sourceware.org > Cc: Rob Landley > Subject: Re: [crosstool-NG] Design discussion > > Rob, > All, > > On Monday 06 April 2009 07:45:49 Rob Landley wrote: > > Ok, I think I left off around here: > > OK, I think I'm coping with the back-log ;-) > > > > 2.b) Ease configuration of the toolchain > > > > > > In the state, configuring crosstool required editing a file > containing > > > shell variables assignements. There was no proper documentation at > what > > > variables were used, and no clear explanations about each > variables > > > meaning. > > My response to this problem was to write documentation. > > Sure. But documentation is not all. Fixing and enhancing both the code > and the configuration scheme is also a way to achieve a better > end-user > experience (Ahaha! I've wandered too much with the marketting dept > lately). > > > While I've used kconfig myself, there's an old saying: "If all you > have is a > > hammer, everything looks like a nail". > > Hehe! Show me a better and simpler way. > > > The failure mode of kconfig is having so much granularity > > So what? Should I restrict what the end-user is allowed to do, based > solely > on my own experience? If the possibility exists in the tools, then why > prevent the user from using (or not using) that? Configuring a > compiler > has soooo many options, it drives you mad. Quite a lot can be inferred > from higher-level options, such as the arch name and the CPU variant, > or > the ABI... > > > Ironically, kconfig is only really worth using when you have enough > config > > options to bother with it. > > But there *are* a lot of options! There isn't even all that could be > available! > > > When you have small numbers of config options > > that are usually going to be off, I prefer environment variables > (with a > > config file in which you can set those in a persistent manner) or > command > > line options. Since you can set an environment variable on the > command line, > > ala: > > > > FORK=1 ./buildall.sh > > > > I lean towards those. Possibly a matter of personal taste... > > I think so. To configure stuff, I prefer having a GUI that is not vi, > but > that is still simple. and the kconfig language and its mconf > interpreter > seems quite fitted, even if it is not the best. But here is no > alternative > that I'm aware of. Plus, it is quite well known thanks to the Linux > kernel > using it. > > > Getting back to menuconfig, since it _is_ so central to your design, > let's > > look at the menuconfig entries. I still have 1.3.2 installed here, > which > > starts with nine sub-menus, let's go into the first, "paths and misc > > options": > > > > The first three options in the first menu aren't immediately useful > to a > > newbie like me: > > > > [ ] Use obsolete features > > [ ] Try features marked as EXPERIMENTAL (NEW) > > [ ] Debug crosstool-NG (NEW) > > I dunno what your obsolete versions are, I don't know what your > experimental > > options are, and I dunno what debugging crosstool-ng does. I am not > > currently qualified to make any decisions about them, because I > don't know > > what they actually control. > > Looking at the help... the "obsolete features" thing seems useless? > We've > > already got menus to select kernel and gcc versions, this just hides > some of > > those versions? Why? (Shouldn't it default to the newest stable > version? > > If it doesn't, shouldn't it be _obvious_ that the newest stable > version is > > probably what you want?) > > OK, obsolete means that I can't afford ensuring that they still build. > > > Marking old versions "deprecated" might make a certain mount of > sense. > > marking them obsolete and hiding them, but still having them > available, less > > so. > > OK, deprecated is much meaningful, I admit to it. Let's set for > s/OBSOLETE/DEPRECATED/, then. > > > Similarly, the "experimental" one seems useless because when you > enable it the > > experimental versions already say "EXPERIMENTAL" in their > descriptions > > (wandered around until I found the binutils version choice menu and > looked at > > it to be sure). They're marked anyway, so why is an option to hide > them an > > improvement? > > EXPERIMENTAL in the prompt is just a string. A config knob makes the > user > really aware that he/she's trying something that might break. > > Plus, it marks the resulting config file as containing EXPERIMENTAL > features/versions/... and is easier to process. > > > As for the third, wasn't there a debug menu? Why is "Debug > crostool-NG" in > > the paths menu? (Rummage, rummage... Ah, I see, the debug menu is a > list of > > packages you might want to build and add to the toolchain. Ok, sort > of makes > > sense. Still, the third thing a newbie sees going through in order > as > > a "very very expert" option. Moving on...) > > That's why the former in titled "Debug crosstol-NG", while the latter > is titled "debug facilities". Again, maybe the wording is wrong. > > > () Local tarballs directory (NEW) > > (${CT_TOP_DIR}/targets) Working directory (NEW) > > (${HOME}/x-tools/${CT_TARGET}) Prefix directory (NEW) > > > > Most users aren't going to care where the local tarballs directory > is, or the > > working directory. > > Most. Not all. And the help entries are here to tel the user whether > it wise to change. > > > The "prefix directory" is presumably different from where > > we just installed with --prefix. > > The help roughly says: the path were the toolchain is expected to run > from. > Unfortunately, there is yet no support for DESTDIR, the place where > the > toolchain will be installed, to allow installing out-of-tree. For the > time > being, the DESTDIR is plainly / that is, the toolchain is expected to > run > on the system it is built on. But that should eventually be fixed. > > > I suppose it's nice that you can override > > the defaults, but having it be one of the first questions a user's > posed with > > when going through the options in order trying to configure the > thing isn't > > really very helpful. It's not my problem, just _work_. > > Where should I install the toolchain? In the user's home directory? > This is indeed the default, but you are pestering against it! > > If not in ${HOME}, where should I install the toolchain? In /opt ? > In /usr/local ? Bah, most useres don't have right access there. > Except root. But building as root is asking for problems! > > > (I also don't know > > what CT_TOP_DIR and CT_TARGET are, I'd have to go look them up.) > > docs/overview.txt is advertised in the top-level README. > > > For comparison, my system creates a tarball from the resulting cross > compiler, > > and leaves an extracted copy as "build/cross-compiler-$ARCH". You > can put > > them wherever you like, it's not my problem. They're fully > relocatable. > > Toolchains built with crosstool-NG are also fully relocatable. > Having the user tell before hand where to install the stuff is also > another good option. > > > [*] Remove documentation (NEW) > > Nice, and possibly the first question someone who _isn't_ a cross > compiler > > toolchain developer (but just wants to build and use the thing) > might > > actually be interested in. > > :-) > > > Your ./configure still requires you to install makeinfo no matter > what this is > > set to. You have to install the package so this can delete its > output? > > Unfortunately, gcc/glibc/... build and install their documentation by > default. I haven't seen any ./configure option that would prevent them > from doing so... :-( > > > Wouldn't it be better to group this with a "strip the resulting > binaries" > > option, and any other space saving switches? (I'm just assuming you > _have_ > > them, somewhere...) > > Nope. But that's a good idea. :-) > > > [*] Render the toolchain read-only (NEW) > > This is something the end user can do fairly easily for themselves, > and I'm > > not quite sure what the advantage of doing it is supposed to be > anyway. In > > any case it's an install option, and should probably go with other > install > > options, but I personally wouldn't have bothered having this option > at all. > > In fact, it's here and ON by default, and why this is so is clearly > explained > both in docs/overview.txt and in the help of this option. Well, that > might not > be so obvious, after all. :-( > > > [ ] Force downloads (NEW) > > I noticed your build doesn't detect whether or not the tarballs > downloaded > > properly. > > Forcing re-downloads every build puts unnecessary strain on the > mirrors, and > > seems a bit impolite. (Plus your re-download can time out halfway > through if > > the net hiccups.) But the alternative you've got is your > infrastructure > > won't notice corrupted tarballs other than by dying. > > Yeah. Sad. Will work on it. until now, it was a minor problem, as > there were > more important ones. Now that most of the stuff is functional, it's > time to > polish things... > > > [ ] Use a proxy (NEW) ---> > > Wow, are these still used in 2009? Ok? (It just never came up for > me...) > > Yes! Big and not-so-big companies have proxies to connect you to the > internet > and they use that as a filter against, well, preventing you from doing > pr0n at > work, or going on other unlawful sites, such as hacking and stuff... > > > [ ] Use LAN mirror (NEW) ---> > > In the sub-menu this options, why do you have individual selections > instead of > > just having 'em provide a URL prefix pointing to the directory in > which to > > find the packages in question? You already know the name of each > package > > you're looking for... > > Hmmm... There must have been a good idea behind that... Can't think of > it > any more... :-( > > > (10) connection timeout (NEW) > > This is an implementation detail. Users should hardly ever care. > > No. I have a case were the network is sooo slow that connections are > established well after the 10s default timeout (17s if I remember > well). > > > My system uses wget instead of curl (because wget is in busybox and > curl > > isn't). > > If you don't have curl, crosstool-NG falls back to using wget. That's > just > a matter of taste, here. And no so many people are using busybox-based > workstations. ;-) > > > As a higher level design issue, It would have been easier for me to > implement > > my build system in python than in bash, but the point of doing it in > bash is > > it's the exact same set of commands you'd run on the command line, > in the > > order you'd run them, to do this yourself by hand. So to an extent > the shell > > scripts act as documentation and a tutorial on how to build cross > compilers. > > (And I added a lot of #comments to help out there, because I > _expect_ people > > to read the scripts if they care about much more than just grabbing > prebuilt > > binary tarballs and using them to cross compile stuff.) > > That paragraph also applies to crosstool-NG. Word for word, except for > the python stuff, that I don't grok. > > > [ ] Stop after downloading tarballs (NEW) > > This seems like it should be a command line option. > > Granted, same answer as for "Force downloads" > > > [ ] Force extractions (NEW) > > Ah, you cache the results of tarball extraction too. I hadn't > noticed. (I > > hadn't bothered to mention that mine's doing it because it's just an > > implementation detail.) > > > > This is one of the things my setupfor function does: it extracts > source into > > build/sources, in a subdirectory with the same name as the package. > > Unfortunately not all package are good boys. Some have a hyphen in the > package name and a dash in the corresponding directory. > > > Again, I detect "good/stale" cached data via sha1sums. > > I'm missing this. It's on my TODO as well, but low priority... > > > [*] Override config.{guess,sub} (NEW) > > I can sort of see this, but it's one of those "you really, really, > really need > > to know what you're doing, and you might be better off patching or > upgrading > > the package in question instead". > > Yep. Some packages still don't know about *-*-linux-ublibc* tuples... > Sigh... > > > [ ] Stop after extracting tarballs (NEW) > > Ditto as for "Stop after downloading tarballs". > > > (1) Number of parallel jobs (NEW) > > My sources/includes.sh autodetects the number of processors and sets > CPUS. > > You can override it by setting CPUS on the command line. (I often > > do "CPUS=1 ./build.sh x86_64" when something breaks so I get more > > understandable error messages.) > > > > In general, I try never to ask the user for information I can > autodetect sane > > defaults for, I just let them override the defaults if they want to. > > At work, we have a build farm whose purpose is to build the firmwares > for our > targets. The machines are quad-CPUs. Deploying a new toolchain needs > not be > done in the snap of fingers, and building the firmwares have the > priority. > So I use that to restrain the number of jobs to run in // . > > > (0) Maximum allowed load (NEW) > > Ooh, that's nice, and something mine doesn't have. > > Yeah! One good point! :-) > > > Personally I've never had > > a clear enough idea of what loadavg's units were to figure out how > it equated > > to slowing down my desktop, and I've actually found that my laptop's > > interactivity going down the drain is almost never due to loadavg, > it's due > > to running out of memory and the thing going swap happy with the > disk pegged > > as constantaly active. (The CPU scheduler is way the heck better > than the > > I/O scheduler, and virtual memory is conceptually horrible and quite > possibly > > _never_ going to be properly fixed at the theoretical level. You > have to > > accurately predict the future in order to do it right, that's > slightly > > _worse_ than solving the halting problem...) > > > > (0) Nice level (NEW) > > Again, trivial to do from the command line: > > I already have # of // jobs, and loadavg. Why not having nice as > well?... > > > [*] Use -pipe (NEW) > > Why would you ever bother the user with this? It's a gcc > implementation > > detail, and these days with a modern 2.6 kernel dentry and page > caches you > > probably can't even tell the difference in benchmarks because the > data never > > actually hits the disk anyway. > > Have you actually benchmarked the difference? > > 10% gain on my machine (Dual AMD64, 1GiB RAM) at the time of testing. > Much less now I have a Quad-core with 4GiB RAM. > > > [ ] Use 'ash' as CONFIG_SHELL (NEW) > > A) I haven't got /bin/ash installed. Presumablly you need to > install it since > > the help says it's calling it from an absolute path? > > crosstool-NG does not build and install it. If the user wants that, > he/she's > responsible for installing it, yes. Maybe I should build my own... > > > B) If your scripts are so slow that you need a faster shell to run > them, > > possibly the problem is with the scripts rather than with the shell? > > My scripts are not so slow. ./configure scripts and Makefiles are. > Again, using dash, the build went 10%/15% faster on my quad-core. > > > I admit that one of the potential weaknesses of my current system is > that it > > calls #!/bin/bash instead of #!/bin/sh. I agonized over that one a > bit. But > > I stayed with bash because A) dash is seriously broken, B) bash has > been the > > default shell of Linux since before the 0.0.1 release. > > I do explicitly call bash as well, because I use bashisms in my > scripts. > ./configure and Makefiles should be POSIX compliant. I am not. > > > Maximum log level to see: (INFO) ---> > > I don't have a decent idea of what you get with each of these. > (Yes, I've > > read the help.) > > OK, that may require a litle bit more explanations in the help. > I don't care about the components build log. I just want to know > whether the > build was successful, or failed. In crosstool-NG the messages are > sorted > in order of importance: > ERROR : crosstool-NG detected an error: failed > download/extract/patch/... > incorrect settings, internal error... ERRORs are fatal > WARNING : non-fatal condition that crosstool-NG knows how to work > around, > but if you better give it correct input, rather than letting > it > guess. > INFO : informs the user of the overall process going on. Very > terse. > Tells the current high-level step being done: doanloading, > extracting, building a component... > EXTRA : informs the user with a finer level of what's going on. For > each steps listed above, prints sub-sequences: package being > downloaded/exxtracted/patched, sub-step in building a > component: > ./configure-ing, make-ing, installing... > DEBUG : messages aimed at debugging crosstool-NG's behavior. > ALL : print everything: ./configure output, make output... > > > Oh, I pull one other dirty trick, at the end of setupfor: > > # Change window title bar to package now > > echo -en "\033]2;$ARCH_NAME $STAGE_NAME $PACKAGE\007" > > So you can see in the window title bar what architecture, stage, and > package > > it's currently building. > > Hmm... Nice! > > > [ ] Warnings from the tools' builds (NEW) > > Again, filtering the output of the build I leave to the user. > They're better > > at it, > > From an end-user perspective (yes, I *am* using crosstool-NG ;-) ), I > don't > care what commands are being executed to build such or such package, > just > that it's doing it, and that it's not stuck. > > > and 90% of the time they just want to know that it's still going, > or > > that it succeeded, or what error it died with. > > Yep. Exactly. > > > But I can only _guess_ what they want, so I don't. > > Not wrong per se. > > > In general, I try not to > > assume they're not going to want to do some insane crazy thing I > never > > thought of, because usually I'm the one doing the insane crazy > things the > > people who wrote the stuff I'm using never thought of, so I > sympathize. > > ;-) > > > [*] Progress bar (NEW) > > I have the "dotprogress" function I use for extracting tarballs, > prints a > > period every 25 lines of input. > > Mine rotates the bar every tenlines. Which is the better? ;-) > > I used to change the color of the output so you could see at a > glance what > > stage it was, but people complained > > Right. crosstool-NG's output used to be colored, but that just plainly > sucks. > And, believe it or not, some people are still using non-color-capable > terminals... > > > [*] Log to a file (NEW) > > Again, "./build.sh 2>&1 | tee out.txt". Pretty much programming 101 > these > > days, if you haven't learned that for building all the other source > packages > > out there, cross compiling probably isn't something you're ready > for. > > Don't believe that. I have seen many a newbie asked to build embedded > stuff > on an exotic board that barely had support for in Linux, said newby > just > getting out of school, totaly amazed at the fact that you could > actually > run something else than Windows on a PC, let alone that something else > than PCs even existed... > > (Well that newbie has grown since, and is now quite a capable Linux > guru). > > > And I'm at the end of this menu, so I'll pause here for now. (And > you were > > apologizing for writing a long message... :) > > I knew you would surpass me in this respect! ;-P > > ( Woohoo! I caught up with your mails! :-) ) > > Regards, > Yann E. MORIN. > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' > conspiracy: | > | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ___ > | > | --==< ^_^ >==-- `------------.-------: X AGAINST | \e/ > There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v > conspiracy. | > `------------------------------^-------^------------------^--------------------' > > > -- > For unsubscribe information see http://sourceware.org/lists.html#faq > > > > -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |