Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Dear Peter Tyser, In message 1248033674.15400.9.ca...@ptyser-laptop you wrote: On Sat, 2009-07-18 at 20:07 +0200, Wolfgang Denk wrote: Dear Peter Tyser, In message 1247935062.9174.14.ca...@ptyser-laptop you wrote: I'd still vote for changing the directory structure in this release, NAK. Such heavily restructuring changes should be prepared and submitted at (or even before) the begin of the merge window, not at it's very end. For this release it's too late for such a change. Any interest in picking up the following patches from this series for the upcoming release: 1/6 Move architecture specific config.mk files into subdirs 5/6 Move examples/ to examples/standalone 6/6 Move api_examples to examples/api They're pretty straightforward and are 3 less changes to carry around. OK, tried that. It worked for 1/6 and 5/6, but 6/6 failed,probably due to missing/not matching context. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. - Frederick Brooks Jr., The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On Tue, 2009-07-21 at 00:15 +0200, Wolfgang Denk wrote: Dear Peter Tyser, In message 1248033674.15400.9.ca...@ptyser-laptop you wrote: On Sat, 2009-07-18 at 20:07 +0200, Wolfgang Denk wrote: Dear Peter Tyser, In message 1247935062.9174.14.ca...@ptyser-laptop you wrote: I'd still vote for changing the directory structure in this release, NAK. Such heavily restructuring changes should be prepared and submitted at (or even before) the begin of the merge window, not at it's very end. For this release it's too late for such a change. Any interest in picking up the following patches from this series for the upcoming release: 1/6 Move architecture specific config.mk files into subdirs 5/6 Move examples/ to examples/standalone 6/6 Move api_examples to examples/api They're pretty straightforward and are 3 less changes to carry around. OK, tried that. It worked for 1/6 and 5/6, but 6/6 failed,probably due to missing/not matching context. Thanks for applying them. I'll send 6/6 in a few minutes. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On Sat, 2009-07-18 at 20:07 +0200, Wolfgang Denk wrote: Dear Peter Tyser, In message 1247935062.9174.14.ca...@ptyser-laptop you wrote: I'd still vote for changing the directory structure in this release, NAK. Such heavily restructuring changes should be prepared and submitted at (or even before) the begin of the merge window, not at it's very end. For this release it's too late for such a change. Any interest in picking up the following patches from this series for the upcoming release: 1/6 Move architecture specific config.mk files into subdirs 5/6 Move examples/ to examples/standalone 6/6 Move api_examples to examples/api They're pretty straightforward and are 3 less changes to carry around. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Dear Peter Tyser, In message 1248033674.15400.9.ca...@ptyser-laptop you wrote: On Sat, 2009-07-18 at 20:07 +0200, Wolfgang Denk wrote: Dear Peter Tyser, In message 1247935062.9174.14.ca...@ptyser-laptop you wrote: I'd still vote for changing the directory structure in this release, NAK. Such heavily restructuring changes should be prepared and submitted at (or even before) the begin of the merge window, not at it's very end. For this release it's too late for such a change. Any interest in picking up the following patches from this series for the upcoming release: 1/6 Move architecture specific config.mk files into subdirs 5/6 Move examples/ to examples/standalone 6/6 Move api_examples to examples/api They're pretty straightforward and are 3 less changes to carry around. I will look into this patch series ASAP (still fighting with some backlog; just completed June's patches) - it was submitted while the merge window was open, so there is no reason to ignore them without at least carefully checking. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Who is the oldest inhabitant of this village? We haven't got one; we had one, but he died three weeks ago. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On 23:39 Tue 14 Jul , Peter Tyser wrote: On Wed, 2009-07-15 at 12:38 +0900, Shinya Kuribayashi wrote: Peter Tyser wrote: On Sun, 2009-07-12 at 14:54 +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: On 22:42 Fri 10 Jul , Mike Frysinger wrote: On Friday 10 July 2009 21:20:45 Shinya Kuribayashi wrote: Peter Tyser wrote: Before verifying MIPS builds, I'd like to make sure that why you take lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any discussion on #IRC, is there any chance we could share the summary or decision to follow? There was no discussion, /lib/$(ARCH) just made more sense to me and it was functionally a direct translation from lib_$(ARCH) to lib/$(ARCH). Using $(ARCH)/lib wouldn't clean up the top-level directory structure much and would open a can of worms that I'm not prepared to deal with at this time. For example, if there was an architecture specific Oops, I wanted to say arch/$(ARCH)/lib/, not $(ARCH)/lib/, sorry. i thought that originally, but i dont care much either way. having arch/$(ARCH)/ would line up with u-boot-v2 and the linux kernel though. i dont understand needing a lib/ subdir under arch/$(ARCH)/ though. While we're talking about it, I'd always thought it would be nice to split out all the cmd_* files from common/ into their own command/ directory similar to u-boot-v2. Ack. The directory structure in u-boot-v2 looks nice, at least, to me, anyway. I prefer the arch/$(ARCH)/lib so will could also move the cpu stuff there too I like the Linux and u-boot-v2 directory layout too the more I think about it too. How about if I resend this series but with the final directory structure looking like: /arch/$(ARCH)/lib/source files currently in lib_$(ARCH) /lib/ /source files currently in lib_generic /libfdt/ /lzma/ /lzo/ /examples/ /api/ /standalone/ That will lay the groundwork for moving additional files into /arch/$(ARCH)/ down the road. eg I think it would be nice to move the directories in /cpu/* into their respective /arch/$(ARCH)/ directory, and possibly the /include/asm-$(ARCH) directories in the long run. What do others think of this? There were some discussions we'd better to reflect back on about this topic. I can't toss the URLs of them at the moment as I'm behind a firewall, but these might help: Date: Thu, 13 Sep 2007 17:28:47 -0600 From: Grant Likely grant.lik...@secretlab.ca To: uboot u-boot-us...@lists.sourceforge.net, Jon Loeliger j...@jdl.com, Wolfgang Denk w...@denx.de Subject: [U-Boot-Users] [RFC] u-boot migration to kconfig Jean-Christophe submitted some patches for consideration earlier this year. No one really bit as far as taking the necessary steps to get the Kbuild system fully functional if my memory is correct. I don't think those patches are going to make it into the upcoming release in any case. I'd vote to get the directory structure changed as desired (in this release), then integrate the Kconfig-based build system in the next release once the directory layout is stable. Jean-Christophe is the most familiar with the Kbuild system and might have a better idea what its state is, how hard it would be to adapt to a new directory layout, etc. Do you have any input Jean-Christophe? more we will be close to the linux organisation more easier it will be to integrate it and update it the only really important think is to merge to KConfig first. Please note that the Kconfig is already ready I just not have the time to rebase the patch before tomorow as I've to do my custudian work first Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
I'd vote to get the directory structure changed as desired (in this release), then integrate the Kconfig-based build system in the next release once the directory layout is stable. Jean-Christophe is the most familiar with the Kbuild system and might have a better idea what its state is, how hard it would be to adapt to a new directory layout, etc. Do you have any input Jean-Christophe? more we will be close to the linux organisation more easier it will be to integrate it and update it Your sentence above implies you'd like the directory structure to match Linux's BEFORE adding Kconfig support... the only really important think is to merge to KConfig first. But this sentence states you'd prefer to change the directory structure AFTER adding Kconfig support? I'd still vote for changing the directory structure in this release, then apply the Kconfig changes in the next one. The same Kconfig files you've already made could still be used regardless of directory layout, correct? ie all you'd have to do is change the source oldpath to source newpath in some Kconfig files and maybe update a Makefile or 2? In any case, one of us would have to fix up the Kconfig support to work with a new directory layout. In my opinion, if its not hard to update the Kconfigs to work with a new directory layout it would make more sense for you to do it at the same time as adding Kconfig support instead of me making both directory layout and Kconfig changes at the same time. Anyway, that's my $.02 Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On 11:37 Sat 18 Jul , Peter Tyser wrote: I'd vote to get the directory structure changed as desired (in this release), then integrate the Kconfig-based build system in the next release once the directory layout is stable. Jean-Christophe is the most familiar with the Kbuild system and might have a better idea what its state is, how hard it would be to adapt to a new directory layout, etc. Do you have any input Jean-Christophe? more we will be close to the linux organisation more easier it will be to integrate it and update it Your sentence above implies you'd like the directory structure to match Linux's BEFORE adding Kconfig support... the only really important think is to merge to KConfig first. But this sentence states you'd prefer to change the directory structure AFTER adding Kconfig support? I do not care that much for the Kconfig but we need to have it before the Kbuild support which is different I'd still vote for changing the directory structure in this release, then apply the Kconfig changes in the next one. The same Kconfig files you've already made could still be used regardless of directory layout, correct? ie all you'd have to do is change the source oldpath to source newpath in some Kconfig files and maybe update a Makefile or 2? In any case, one of us would have to fix up the Kconfig support to work with a new directory layout. In my opinion, if its not hard to update the Kconfigs to work with a new directory layout it would make more sense for you to do it at the same time as adding Kconfig support instead of me making both directory layout and Kconfig changes at the same time. that's fine for me Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Hi Rafal, I like the Linux and u-boot-v2 directory layout too the more I think about it too. How about if I resend this series but with the final directory structure looking like: /arch/$(ARCH)/lib/source files currently in lib_$(ARCH) /lib/ /source files currently in lib_generic /libfdt/ /lzma/ /lzo/ /examples/ /api/ /standalone/ Not directly answering your question, but rather a minor naming nit: strictly speaking the 'api' subdir contents are also standalone applications... so the above naming scheme is not clear cut, although I don't have much better suggestions :-) The 'standalone' above use the legacy jumptable calls method, so maybe 'jumptable' dirname would work? Other thoughts? I see your point. nitpickIts a bit confusing as U-Boot documentation seems to refer to Standalone applications alot, and in general that documentation is specifically referring jumptable applications. eg doc/README.standalone and Standalone HOWTO in README. If you dig you can find the API applications mentioned in api/README - I don't see it referenced much in either the standard location of /doc/* or /README. I guess my only point is that it would be great if the application documentation was consistent between the jumptable and API method, then it would be a a no brainer as far as naming /examples directory layout. As is, documentation implies standalone application means jumptable application./nitpick In any case, I'm OK with a different directory layout. /examples/[api| jumptable] is fine, or we could even add an apps subdir, eg: /examples/apps/[api|jumptable]. I'm also fine with leaving it the way I had it initially as all documentation currently implies standalone == jumptable, api = API method. Let me know if you or others have arguments for 1 convention over another. Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Dear Peter Tyser, In message 1247935062.9174.14.ca...@ptyser-laptop you wrote: I'd still vote for changing the directory structure in this release, NAK. Such heavily restructuring changes should be prepared and submitted at (or even before) the begin of the merge window, not at it's very end. For this release it's too late for such a change. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Deliver yesterday, code today, think tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Dear Peter Tyser, In message 1247935976.9174.31.ca...@ptyser-laptop you wrote: I see your point. nitpickIts a bit confusing as U-Boot documentation seems to refer to Standalone applications alot, and in general that documentation is specifically referring jumptable applications. eg doc/README.standalone and Standalone HOWTO in README. If you dig you can find the API applications mentioned in api/README - I don't see it referenced much in either the standard location of /doc/* or /README. I guess my only point is that it would be great if the application documentation was consistent between the jumptable and API method, then it would be a a no brainer as far as naming /examples directory layout. As is, documentation implies standalone application means jumptable application./nitpick Agreed. So far it seems that the *BSD boot loader folks are the only users of and the only developers interested in the API code. eg: /examples/apps/[api|jumptable]. I'm also fine with leaving it the way I had it initially as all documentation currently implies standalone == jumptable, api = API method. Agreed - that should besufficiently clear - at least for now. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de After a time, you may find that having is not so pleasing a thing, after all, as wanting. It is not logical, but it is often true. -- Spock, Amok Time, stardate 3372.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Hi Peter, On 2009-07-14, at 17:20, Peter Tyser wrote: I like the Linux and u-boot-v2 directory layout too the more I think about it too. How about if I resend this series but with the final directory structure looking like: /arch/$(ARCH)/lib/source files currently in lib_$(ARCH) /lib/ /source files currently in lib_generic /libfdt/ /lzma/ /lzo/ /examples/ /api/ /standalone/ Not directly answering your question, but rather a minor naming nit: strictly speaking the 'api' subdir contents are also standalone applications... so the above naming scheme is not clear cut, although I don't have much better suggestions :-) The 'standalone' above use the legacy jumptable calls method, so maybe 'jumptable' dirname would work? Other thoughts? Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On Sun, 2009-07-12 at 14:54 +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: On 22:42 Fri 10 Jul , Mike Frysinger wrote: On Friday 10 July 2009 21:20:45 Shinya Kuribayashi wrote: Peter Tyser wrote: Before verifying MIPS builds, I'd like to make sure that why you take lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any discussion on #IRC, is there any chance we could share the summary or decision to follow? There was no discussion, /lib/$(ARCH) just made more sense to me and it was functionally a direct translation from lib_$(ARCH) to lib/$(ARCH). Using $(ARCH)/lib wouldn't clean up the top-level directory structure much and would open a can of worms that I'm not prepared to deal with at this time. For example, if there was an architecture specific Oops, I wanted to say arch/$(ARCH)/lib/, not $(ARCH)/lib/, sorry. i thought that originally, but i dont care much either way. having arch/$(ARCH)/ would line up with u-boot-v2 and the linux kernel though. i dont understand needing a lib/ subdir under arch/$(ARCH)/ though. While we're talking about it, I'd always thought it would be nice to split out all the cmd_* files from common/ into their own command/ directory similar to u-boot-v2. Ack. The directory structure in u-boot-v2 looks nice, at least, to me, anyway. I prefer the arch/$(ARCH)/lib so will could also move the cpu stuff there too I like the Linux and u-boot-v2 directory layout too the more I think about it too. How about if I resend this series but with the final directory structure looking like: /arch/$(ARCH)/lib/source files currently in lib_$(ARCH) /lib/ /source files currently in lib_generic /libfdt/ /lzma/ /lzo/ /examples/ /api/ /standalone/ That will lay the groundwork for moving additional files into /arch/$(ARCH)/ down the road. eg I think it would be nice to move the directories in /cpu/* into their respective /arch/$(ARCH)/ directory, and possibly the /include/asm-$(ARCH) directories in the long run. What do others think of this? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On Tuesday 14 July 2009 17:20:43 Peter Tyser wrote: I prefer the arch/$(ARCH)/lib so will could also move the cpu stuff there too I like the Linux and u-boot-v2 directory layout too the more I think about it too. How about if I resend this series but with the final directory structure looking like: /arch/$(ARCH)/lib/source files currently in lib_$(ARCH) /lib/ /source files currently in lib_generic /libfdt/ /lzma/ /lzo/ /examples/ /api/ /standalone/ That will lay the groundwork for moving additional files into /arch/$(ARCH)/ down the road. eg I think it would be nice to move the directories in /cpu/* into their respective /arch/$(ARCH)/ directory, and possibly the /include/asm-$(ARCH) directories in the long run. What do others think of this? I like this idea. So +1 from me. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On Wed, 2009-07-15 at 12:38 +0900, Shinya Kuribayashi wrote: Peter Tyser wrote: On Sun, 2009-07-12 at 14:54 +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: On 22:42 Fri 10 Jul , Mike Frysinger wrote: On Friday 10 July 2009 21:20:45 Shinya Kuribayashi wrote: Peter Tyser wrote: Before verifying MIPS builds, I'd like to make sure that why you take lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any discussion on #IRC, is there any chance we could share the summary or decision to follow? There was no discussion, /lib/$(ARCH) just made more sense to me and it was functionally a direct translation from lib_$(ARCH) to lib/$(ARCH). Using $(ARCH)/lib wouldn't clean up the top-level directory structure much and would open a can of worms that I'm not prepared to deal with at this time. For example, if there was an architecture specific Oops, I wanted to say arch/$(ARCH)/lib/, not $(ARCH)/lib/, sorry. i thought that originally, but i dont care much either way. having arch/$(ARCH)/ would line up with u-boot-v2 and the linux kernel though. i dont understand needing a lib/ subdir under arch/$(ARCH)/ though. While we're talking about it, I'd always thought it would be nice to split out all the cmd_* files from common/ into their own command/ directory similar to u-boot-v2. Ack. The directory structure in u-boot-v2 looks nice, at least, to me, anyway. I prefer the arch/$(ARCH)/lib so will could also move the cpu stuff there too I like the Linux and u-boot-v2 directory layout too the more I think about it too. How about if I resend this series but with the final directory structure looking like: /arch/$(ARCH)/lib/source files currently in lib_$(ARCH) /lib/ /source files currently in lib_generic /libfdt/ /lzma/ /lzo/ /examples/ /api/ /standalone/ That will lay the groundwork for moving additional files into /arch/$(ARCH)/ down the road. eg I think it would be nice to move the directories in /cpu/* into their respective /arch/$(ARCH)/ directory, and possibly the /include/asm-$(ARCH) directories in the long run. What do others think of this? There were some discussions we'd better to reflect back on about this topic. I can't toss the URLs of them at the moment as I'm behind a firewall, but these might help: Date: Thu, 13 Sep 2007 17:28:47 -0600 From: Grant Likely grant.lik...@secretlab.ca To: uboot u-boot-us...@lists.sourceforge.net, Jon Loeliger j...@jdl.com, Wolfgang Denk w...@denx.de Subject: [U-Boot-Users] [RFC] u-boot migration to kconfig Jean-Christophe submitted some patches for consideration earlier this year. No one really bit as far as taking the necessary steps to get the Kbuild system fully functional if my memory is correct. I don't think those patches are going to make it into the upcoming release in any case. I'd vote to get the directory structure changed as desired (in this release), then integrate the Kconfig-based build system in the next release once the directory layout is stable. Jean-Christophe is the most familiar with the Kbuild system and might have a better idea what its state is, how hard it would be to adapt to a new directory layout, etc. Do you have any input Jean-Christophe? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On 22:42 Fri 10 Jul , Mike Frysinger wrote: On Friday 10 July 2009 21:20:45 Shinya Kuribayashi wrote: Peter Tyser wrote: Before verifying MIPS builds, I'd like to make sure that why you take lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any discussion on #IRC, is there any chance we could share the summary or decision to follow? There was no discussion, /lib/$(ARCH) just made more sense to me and it was functionally a direct translation from lib_$(ARCH) to lib/$(ARCH). Using $(ARCH)/lib wouldn't clean up the top-level directory structure much and would open a can of worms that I'm not prepared to deal with at this time. For example, if there was an architecture specific Oops, I wanted to say arch/$(ARCH)/lib/, not $(ARCH)/lib/, sorry. i thought that originally, but i dont care much either way. having arch/$(ARCH)/ would line up with u-boot-v2 and the linux kernel though. i dont understand needing a lib/ subdir under arch/$(ARCH)/ though. While we're talking about it, I'd always thought it would be nice to split out all the cmd_* files from common/ into their own command/ directory similar to u-boot-v2. Ack. The directory structure in u-boot-v2 looks nice, at least, to me, anyway. I prefer the arch/$(ARCH)/lib so will could also move the cpu stuff there too for the command dir why not Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Hi, Peter Tyser wrote: This series moves api_examples to api/examples and moves all lib* directories into a common lib/ directory. It also moves the ARCH_config.mk files into their corresponding lib directory. Seeing 12 lib_ARCH directories and 12 ARCH_config.mk files in U-Boot's top level always annoyed me, Me, too. Before verifying MIPS builds, I'd like to make sure that why you take lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any discussion on #IRC, is there any chance we could share the summary or decision to follow? Please note that I agree with such cleanup, of course. I just would like to make sure that lib/$(ARCH)/ is an authorized policy or not. If authorized one, I'm fine. Thanks in advance, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On Sat, 2009-07-11 at 09:03 +0900, Shinya Kuribayashi wrote: Hi, Peter Tyser wrote: This series moves api_examples to api/examples and moves all lib* directories into a common lib/ directory. It also moves the ARCH_config.mk files into their corresponding lib directory. Seeing 12 lib_ARCH directories and 12 ARCH_config.mk files in U-Boot's top level always annoyed me, Me, too. Before verifying MIPS builds, I'd like to make sure that why you take lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any discussion on #IRC, is there any chance we could share the summary or decision to follow? There was no discussion, /lib/$(ARCH) just made more sense to me and it was functionally a direct translation from lib_$(ARCH) to lib/$(ARCH). Using $(ARCH)/lib wouldn't clean up the top-level directory structure much and would open a can of worms that I'm not prepared to deal with at this time. For example, if there was an architecture specific directory, it would seem logical to put cpus of that $(ARCH) type in it too, eg ppc/ lib/ mpc8260 mpc85xx/ mpc86xx/ sh/ lib/ sh2/ sh3/ sh4/ ... My change was just meant to be an incremental improvement, but I could see advantages to using the $(ARCH)/... structure if we wanted to make larger changes. Anyway, I'd be curious to hear other's opinions about other directory layouts. While we're talking about it, I'd always thought it would be nice to split out all the cmd_* files from common/ into their own command/ directory similar to u-boot-v2. Please note that I agree with such cleanup, of course. I just would like to make sure that lib/$(ARCH)/ is an authorized policy or not. If authorized one, I'm fine. I was just scratching an itch, nothing official:) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Peter Tyser wrote: Before verifying MIPS builds, I'd like to make sure that why you take lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any discussion on #IRC, is there any chance we could share the summary or decision to follow? There was no discussion, /lib/$(ARCH) just made more sense to me and it was functionally a direct translation from lib_$(ARCH) to lib/$(ARCH). Using $(ARCH)/lib wouldn't clean up the top-level directory structure much and would open a can of worms that I'm not prepared to deal with at this time. For example, if there was an architecture specific Oops, I wanted to say arch/$(ARCH)/lib/, not $(ARCH)/lib/, sorry. directory, it would seem logical to put cpus of that $(ARCH) type in it too, eg ppc/ lib/ mpc8260 mpc85xx/ mpc86xx/ sh/ lib/ sh2/ sh3/ sh4/ ... My change was just meant to be an incremental improvement, but I could see advantages to using the $(ARCH)/... structure if we wanted to make larger changes. Anyway, I'd be curious to hear other's opinions about other directory layouts. While we're talking about it, I'd always thought it would be nice to split out all the cmd_* files from common/ into their own command/ directory similar to u-boot-v2. Ack. The directory structure in u-boot-v2 looks nice, at least, to me, anyway. Please note that I agree with such cleanup, of course. I just would like to make sure that lib/$(ARCH)/ is an authorized policy or not. If authorized one, I'm fine. I was just scratching an itch, nothing official:) Got it. Thanks for the kind explanation, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On Friday 10 July 2009 21:20:45 Shinya Kuribayashi wrote: Peter Tyser wrote: Before verifying MIPS builds, I'd like to make sure that why you take lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any discussion on #IRC, is there any chance we could share the summary or decision to follow? There was no discussion, /lib/$(ARCH) just made more sense to me and it was functionally a direct translation from lib_$(ARCH) to lib/$(ARCH). Using $(ARCH)/lib wouldn't clean up the top-level directory structure much and would open a can of worms that I'm not prepared to deal with at this time. For example, if there was an architecture specific Oops, I wanted to say arch/$(ARCH)/lib/, not $(ARCH)/lib/, sorry. i thought that originally, but i dont care much either way. having arch/$(ARCH)/ would line up with u-boot-v2 and the linux kernel though. i dont understand needing a lib/ subdir under arch/$(ARCH)/ though. While we're talking about it, I'd always thought it would be nice to split out all the cmd_* files from common/ into their own command/ directory similar to u-boot-v2. Ack. The directory structure in u-boot-v2 looks nice, at least, to me, anyway. makes sense to me too -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
