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 Yann, I understand your reasoning in having a known list of "supported" kernels, but I also think flexibility/scalability is important and giving the ability to deploy this in as many environments as in any way possible. Crosstool-ng already provides a quite broad set of sample configurations which have always worked for me. I just think it's easier to understand that if I change a config option from it's default value it might break something than it not being available. Using the pre-existing set of headers doesn't work well for what I'm using this tool for, either I'd have to write a wrapping makefile around crosstool taking care of preparation of the kernel headers or I'd have to instruct people in how to do so. Also, I like that kernel header preparation is part of this tool, it makes sense. I really like you're idea of doing this through the kernel "drop down list", of course protected by experimental. Just my .10$ Best regards, Stefan Hallas Andersen Cisco Systems Inc. On Wed, 2009-04-01 at 13:02 -0700, Yann E. MORIN wrote: > Stefan, > All, > > On Wednesday 01 April 2009 19:32:36 Stefan Hallas Andersen wrote: > > Attached is a patch to crosstool-ng v.1.3.2 which will prompt for a > > kernel version to be used instead of a static list, > > The 1.3 series will not have new features added: it is in maintenance > only > and gets only bugfixes. > > New features are added on /trunk, and once that is ready, a branch for > the new series will be created, and in its turn will get only > bug-fixes, > while new features get again added to /trunk. > > And /trunk has much more kernel versions available than the /old/ 1.3 > branch. > > > Now, feature-wise, prompting for the version as a string rather than > as a list makes the kernel menu different from the other components, > unless all components are migrated to this. > > It also means crostool-NG can no longer offer a comprehensive patchset > for each supported version of each component. At least, it makes it > harder to maintain... > > Also, it is error-prone, as the user can make a typo while entering > the > version string. > > Know also, that you can direct crosstool-NG to using a pre-existing > set of headers by using the option KERNEL_LINUX_USE_CUSTOM_DIR (in the > 1.3 series), and KERNEL_LINUX_USE_CUSTOM_HEADERS (in trunk). > > On the other hand, we can add an entry to the version list that would > allow the user to enter the version as a string, but that would be > correctly protected behind EXPERIMENTAL, so that the user is informed > he/she's at risk when not using the available versions from the list. > > 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |