On 03/05/2018 15:21, Sebastian Huber wrote: > On 03/05/18 03:55, Chris Johns wrote: >> On 02/05/2018 21:25, Sebastian Huber wrote: >>> On 02/05/18 13:18, Joel Sherrill wrote: >>>> On Wed, May 2, 2018, 12:13 AM Sebastian Huber >>>> <sebastian.hu...@embedded-brains.de >>>> <mailto:sebastian.hu...@embedded-brains.de>> wrote: >>>> > I think that's it from my notes. Any comments or thoughts? >>>> >>>> I would leave the source files in cpukit where they are. A proper >>>> file >>>> history is more important than a fancy directory layout from my >>>> point of >>>> view >>>> >>>> Doesn't got keep history with moves and renames? >>> It works to some extent. You usually need a --follow command line option. >>> It is >>> not completely transparent. >>> >> I think not allowing code movement in the cpukit as a rule is too >> restrictive. I >> do not support such a restriction. I think code can be moved in the cpukit >> tree. >> >> I would have questioned the 'dev' tree being added if I knew this restriction >> existed. I think adding 'dev' is a good change and we should look to move >> parts >> that existed before it was created into it. I think a sensible layout is >> worth >> more than the linear history for _those_ pieces of code. >> >> The RTEMS code base is old and if we had not moved files we would be in a >> tragic >> place. The moving of the headers and BSP code is a good example of why we >> need >> to move source and the threshold for those files to move was higher than the >> need for a clean history. We need to be smart about what we move, why we >> want to >> move things and when. The threshold to move files in rtems, sapi and score is >> very high. This does not rule out moving files in those directories, it just >> means we need to balance the cost/benefit ratio when deciding. A clean >> history >> for those directories and files is important and highly rated. >> >> Give the extent of code moved for RTEMS 5 I am OK with the directories Joel >> has >> listed moving. I welcome the cpukit being cleaned up. >> >> Chris >> >> ps Please reconsider using terms like "fancy directory layout", it is not >> helpful in a discussion about moving files after you have moved most of the >> c/src (which is a fantastic thing to have happened). > > The header file movements were driven by the need to get rid of the preinstall > step. This is a clear benefit. The movements of the BSP source files are a > consequence of this.
Agreed. > If you really want to clean up the cpukit source files, then please create a > ticket and make a plan. This is Joel's to manage. > I am strongly opposed to move files in rtems, sapi and score. Noted. I do not see any movement in those directories for the foreseeable future. 15 years ago I thought the BSPs would never move. My open response is about the time frame we are talking about, 10, 15 or even more years? I can still type 'c/src/lib/libbsp' without thinking about it. At least at my age it will not take long to forget. > It should be carried out before the 5.1 release. Agreed. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
