On Fri, 26 Oct 2007, David McCullough wrote: > > Jivin Robert P. J. Day lays it down ... > > > > really? that's just weird, having the CVS repo lagging behind > > tarball snapshots. what's the rationale for *that*? it certainly > > flies in the face of standard convention. > > People wanted it to reduce downloads, we didn't want to maintain yet > another source tree, so we compromised, and the uClinux-dist CVS > just receives a copy of the latest tarball whenever it is ready, > thus the merges are zero effort for us, and other can benefit from > reduce downloads and between version revisions. > > This has been discussed many times over the years and I am sure you > can find a much better response in the archives, somewhere :-)
ok, fair enough. > > > > $ make menuconfig > > > > $ make vendor_hwselect SPSYTF=... > > > > > > Not sure what vendor_hwselect is, unless it's short hand for > > > some interactive process. > > > > these instructions are not being done from within the kernel > > directory, they're being done one level up in the uclinix > > top-level directory. that may be where you're getting confused. > > I figured that was the case, it's just been so long since we put the > vendor_* target in, and no one much uses it, so I had completely > forgotten about it ;-) > > Sounds a little bit like "make vendor_hwselect" should be part of > the "make menuconfig" somehow. It's generally best to be able to > build a target without having to enter any platform specific > settings, like the SPSYTF=... thing above. i agree completely, but i can see how the out-of-tree build structure is doing a fair bit of work, at least in the case of nios2. ideally, it would be nice to fold that work into the basic in-tree config process. from a very brief perusal, it looks like it could be done but it's definitely not a high priority item on my list. :-) > > > Building the dist with a 2.6 kernel is usually: > > > > > > make config/menuconfig/xconfig > > > make > > > > > > Everything else should get done for you. > > > > > > > $ mkdir romfs [manually] > > > > > > Why do you need to "mkdir romfs" ? > > > > because the default uclinux "make" target wants a destination > > directory for INITRAMFS_SOURCE. if that directory doesn't exist, the > > make complains. you can also, AFAICT, run "make romfs", but just > > creating the directory explicitly with "mkdir" seems sufficient. > > Most if not all targets in the dist have always been a: > > build kernel > build libs > build apps > jpin them together > > approach. I realise that INITRAMFS_SOURCE breaks this. Of course, > you can't have your initramfs until you have your apps built, and > you really need you kernel and modules built before that anyway. > It's a bit like putting the cart before that horse ;-) > > If you want to persevere with INITRAMFS_SOURCE, I would make your > vendor_hwselect create the romfs dir for now. > > If you ever remove that step, perhaps we can look at some way of > automating it for any target that choose to use INITRAMFS_SOURCE. the culprit here is the file vendors/Altera/nios2nommu/config.linux-2.6.x, which contains the config line: CONFIG_INITRAMFS_SOURCE="../romfs ../vendors/Altera/nios2nommu/romfs_list" AFAICT, that forces the kernel build to *require* that romfs directory, even if nothing is placed in it. that's kind of annoying, and i'll see if i can fix that. > > > > $ NON_SMP_BUILD=1 make linux > > > > > > Building the kernel is the first step, so the following will do: > > > > > > make NON_SMP_BUILD=1 > > > > > > but > > > > > > make NON_SMP_BUILD=1 linux > > > > > > is also ok. On the bleeding edge dists you can run: > > > > > > make single > > > > ok, i'll take your word for it, i've never seen that before. > > For reference (and the benefit of others): > > make single > make single_linux > make single_lib_only > make single_user_only > make single_user/init_only > make single_user/init_romfs > ... > > In other words, prefix any build target with "single[_]*" and it > disables the multithreaded build support, i just tried that with my CVS checked out uclinux, and it knows nothing about "single_"-prefixed targets. how curious. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
