Re: New OS_CLASS to epics-base

[Michael Davidsaver <mdavidsaver@gmail.com>]

> Discussion on this from anyone else?

For my part, I don't like the idea of another OS class.  As mentioned it
will necessitate changes to Makefiles of almost every module which
supports RTEMS.  To me, this much churn would need a very compelling reason.


@Heinz, will it be the case that code for >4.10 doesn't work with
<=4.10?  I had hoped that the conditionals could be limited to a few
'#ifdef'.


On 11/30/2016 07:02 PM, Andrew Johnson wrote:
> Hello Heinz,
> 
> On 11/30/2016 10:56 AM, Heinz Junkes wrote:
>> Is there a guideline how to add a new OS_CLASS to epics-base ?
> 
> I'm not aware of anything written down. The Application Developers Guide
> section on the Build system lists the classes known at the time the
> document was written, but says nothing about adding new classes.
> 
>> My suggestion : In addition to RTEMS : RTEMS-4.12
> 
> The value of OS_CLASS is used in a couple of different ways, so we have
> to be slightly careful about which characters to use. The main uses I
> know of are:
> 
>  * Source directories (e.g. src/libCom/osi/os/*, include/os/*)
>  * Makefile variables (e.g. PROD_*, LIB_SRCS_*, USR_CFLAGS_* etc.)
> 
> GNUMake's variable names are more flexible that you might expect and
> both . and - are legal in variable names, although the results might
> look slightly strange to some people.
> 
> Note that adding a second RTEMS OS_CLASS means any support applications
> that currently have something like this in their Makefiles
> 
>   PROD_vxworks = Vxxx
>   PROD_RTEMS = Rxxx
>   PROD_default = xxx
> 
> will try to build the workstation product xxx for RTEMS-4.12 if Base is
> configured to build one of the new RTEMS targets, which is probably the
> wrong target. To change that the Makefile would need an additional line
> such as
> 
>   PROD_RTEMS-4.12 = Rxxx
> 
> That variable name looks a little strange as I mentioned above, and it's
> a pity to have to force support module authors to add an extra line like
> this.
> 
>> The next could then be RTEMS-SMP ?
> 
> Do you think you would need yet /another/ OS_CLASS for the SMP version?
> I would much prefer to have one class handle both unless you really
> can't avoid it, and in fact considering my discussion above I'm
> wondering if the idea of adding a second OS_CLASS for RTEMS is the right
> thing to do after all.
> 
> It might be better to configure the libCom build to search different
> source directories depending on the RTEMS version number, or on some
> target-specific setting given in the CONFIG_SITE.Common.RTEMS-<arch>
> file. I will help with doing this if you want to go that way.
> 
> You could also consider putting different implementations in different
> source files under osi/os/RTEMS and have the main osd*.c files #include
> one or other of the implementations, but this doesn't solve situations
> where your new version wants to throw away the old implementation and
> just use the copy in the osi/os/posix directory. I think my previous
> idea could be made to work with that.
> 
> Discussion on this from anyone else?
> 
> - Andrew
>