Re: [lwip-users] multiple timers.c in project

[Fabian Cenedese]

At 19:14 18.07.2014, FreeRTOS Info wrote:


>On 18/07/2014 17:32, Simon Goldschmidt wrote:
>>"Sebastian Subik" wrote:
>>
>>>I hoped that there are better solutions available, but your
>>>solution should definitely work. Maybe lwip can consider renaming
>>>their timers.c within a future release to avoid such kind of
>>>problems...
>>
>>You could ask the same from FreeRTOS. In fact, <sarcasm> why doesn't
>>every project rename every source file to have the project name as a
>>prefix? That would be a great idea! </sarcasm>
>
>There are a couple of things it would be nice to have the freedom to change in 
>FreeRTOS - the file names is top of the list.  List.c in particular - would be 
>better as FreeRTOS_List.c.  I really don't think it is any hassle to change 
>the name of one file in your project though - but do understand it is more 
>problematic when it comes to header file name clashes.
>
>When FreeRTOS was created, and probably lwIP too, there was no anticipation of 
>its massive uptake, hence it maybe lacked a bit of forward thinking about how 
>it would fit into larger projects.  On top of that, at the time it was 
>created, the file names all had to fit into 8.3 format too.
>
>Nearly all such "if only we had done..." wishes have been morphed into 
>FreeRTOS over the years, and our newer products (both written already and 
>being written) do not have these naming problems.  We can't, however, change 
>the name of a file for such a well established product as the core FreeRTOS 
>kernel though without causing a major upset - there are so many third party 
>tools that use the files, or copy the files around, or display the files, etc. 
>and that is not even mentioning the thousands and thousands of users who would 
>have to change their project files and scripts in order to update their 
>version of FreeRTOS were the file names to change (a process that normally 
>just requires a drop in replacement followed by a clean build).

Just an idea, I'm not concerned by this problem (yet): What about renaming
the files to some project_content.ext scheme, then creating files in the old
content.ext scheme that just #includes the <project_content.ext> files?

New user projects or those with the mentioned problems can use the new
scheme, existing projects can use the old scheme and don't need to be
adjusted.

bye  Fabi