Hello,
I was wondering whether CMake support or an example is available or will be
added in the future. We are using a framework which has different
abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but
we would like to use the same build system to build applications and
Hello Robin,
you can use whatever build system you want to build your applications.
You can use pkgconfig to get the necessary flags for a particular BSP
installation.
On 09/12/2020 13:50, Robin Müller wrote:
I also had another question about a specific flag used when linking
RTEMS executabl
Thank you Sebastian. I'm looking at building the example erc32 application
and the blinky executable right now. There is the issue
that determining the BSP path,tool binary determination, all the checking
etc.. bleeds into the application CMakeLists.txt but there is
probably a good way to extract t
On Wed, Dec 9, 2020 at 8:06 AM Robin Müller
wrote:
> Thank you Sebastian. I'm looking at building the example erc32 application
> and the blinky executable right now. There is the issue
> that determining the BSP path,tool binary determination, all the checking
> etc.. bleeds into the application
On 10/12/20 1:18 am, Joel Sherrill wrote:
> As I read this thread, this morning, it occurred to me that the Users
> Manual needs a chapter on build systems for end user applications.
> It needs to cover fetching the settings from the pkgconfig files and using
> waf, old Makefile infrastructure, et
Hello,
I created a repository on github for the first version of what a CMake
support for RTEMS might look like:
https://github.com/rmspacefish/rtems-cmake
I tried to extract generic components like determining library paths into
functions (RTEMSGeneric.cmake)
and there is a hardware specific
On 11/12/20 8:51 am, Robin Müller wrote:
> Hello,
>
> I created a repository on github for the first version of what a CMake support
> for RTEMS might look like:
>
> https://github.com/rmspacefish/rtems-cmake
> <https://github.com/rmspacefish/rtems-cmake>
>
Awesom
On Thu, Dec 10, 2020 at 5:58 PM Chris Johns wrote:
> On 11/12/20 8:51 am, Robin Müller wrote:
> > Hello,
> >
> > I created a repository on github for the first version of what a CMake
> support
> > for RTEMS might look like:
> >
> > https://git
Hi all,
> I was wondering whether CMake support or an example is available or will
be added in the future. We are using a framework which has different
abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but
we would like to use the same build system to build applications
would be good so more hardware configurations can be added without having
to build every BSP.
Kind Regards
Robin
On Fri, 11 Dec 2020 at 10:59, Stanislav Pankevich
wrote:
> Hi all,
>
> > I was wondering whether CMake support or an example is available or
> will be added in the futur
ns can be added without having
> to build every BSP.
>
> Kind Regards
> Robin
>
> On Fri, 11 Dec 2020 at 10:59, Stanislav Pankevich
> wrote:
>
>> Hi all,
>>
>> > I was wondering whether CMake support or an example is available or
>> will be added in
On 12/12/20 6:09 am, Robin Müller wrote:
> I added the suggestions by Chris Johns now and performed some more tests (for
> example disabling the default compiler checks, custom checks are required for
> RTEMS).
>
> I used RTEMS_PREFIX instead of PREFIX
These are 2 parts that need to be specified,
Stanislav Pankevich <mailto:s.pankev...@gmail.com>> wrote:
>
> Hi all,
>
> > I was wondering whether CMake support or an example is available or will
> be added in the future. We are using a framework which has different
> abstraction layers for OSes li
On 11/12/20 8:58 pm, Stanislav Pankevich wrote:
> Having this said, I would like to avoid pushing the CMake-way of doing things
> as
> a better way.
Yeah, lets put that to one side. That is a topic for a coffee or a bar ... one
day :)
> Instead, I could contribute feedback to Robin's work here:
Hi.
I now implemented pkg-config parsing and it works nicely with the tools
given by CMake / kitware. I was able to build the hello application with
the automatic pkg flag parsing for sparc/erc32, sparc/leon3 and arm/stm32h7.
I do not know exactly when this feature was added to be honest. I set th
On 14/12/20 8:26 pm, Robin Müller wrote:
> Hi.
>
> I now implemented pkg-config parsing and it works nicely with the tools given
> by
> CMake / kitware. I was able to build the hello application with the automatic
> pkg flag parsing for sparc/erc32, sparc/leon3 and arm/stm32h7.
Awesome.
> I do
This patch adds CMake support to RTEMS lwIP.
It also improves the architecture to make integration
of new BSPs easier.
https://github.com/rmspacefish/rtems-stm32-lwip is a self-contained
repository to test the lwIP integration for the arm/stm32h7
and arm/nucleo-h743zi BSP.
The STM32 port
This patch adds CMake support to RTEMS lwIP.
It also improves the architecture to make integration
of new BSPs easier.
https://github.com/rmspacefish/rtems-stm32-lwip is a self-contained
repository to test the lwIP integration for the arm/stm32h7
and arm/nucleo-h743zi BSP.
The STM32 port
This patch adds full CMake support for the lwIP support.
It can be easily extended to other architectures as well.
More information can also be found in the README, which also specifies
how to build with CMake. The waf build system still needs to be adapted
to perform the same function
obin Mueller wrote:
>
> This patch adds CMake support to RTEMS lwIP.
> It also improves the architecture to make integration
> of new BSPs easier.
>
> https://github.com/rmspacefish/rtems-stm32-lwip is a self-contained
> repository to test the lwIP integration for the arm/stm32h7
On 27/04/2021 17:23, Gedare Bloom wrote:
I can try to get a better license for the files taken from the example. If that
doesn't work out, I guess some scripting will be necessary. The problem is that
these files were modified
to be usable for RTEMS..
Thanks. It might require iterating with
.
The simplest solution would still be a CMakeLists.txt file in the root here
which simply sets source files and include paths in the parent scope.
which would again be another form of maintenance burden because it still
needs to figure out which port sources to add etc.
The rtems-cmake support is ab
ets source files and include paths in the parent scope.
> which would again be another form of maintenance burden because it still
> needs to figure out which port sources to add etc.
> The rtems-cmake support is able to live without CMakeLists.txt files in
> RTEMS because the BSP is alre
her form of maintenance burden because it still
> needs to figure out which port sources to add etc.
> The rtems-cmake support is able to live without CMakeLists.txt files in RTEMS
> because the BSP is already compiled at that point. Doing something similar
> would require a similar proc
s released? As the person
who releases RTEMS I do not have the time or capability to do this.
> The rtems-cmake support is able to live without CMakeLists.txt files in RTEMS
> because the BSP is already compiled at that point. Doing something similar
> would require a similar process l
>
> What about scons, meson, or a plain Makefile for those who just want to use
> make, then there is GNU make and BSD make, the list is large? Do we open
> the
> repo up so all build systems are welcome? I think we would have to so we
> are not
> picking favourites.
>
gt; > to figure out which port sources to add etc.
>>
>> What about scons, meson, or a plain Makefile for those who just want to
>> use
>> make, then there is GNU make and BSD make, the list is large? Do we open
>> the
>> repo up so all build systems are welcome?
nce burden because it still
>>> > needs
>>> > to figure out which port sources to add etc.
>>>
>>> What about scons, meson, or a plain Makefile for those who just want to use
>>> make, then there is GNU make and BSD make, the list is large? Do we open
>> > The simplest solution would still be a CMakeLists.txt file in the root
> >>> > here
> >>> > which simply sets source files and include paths in the parent scope.
> >>> > which would again be another form of maintenance burden be
ly sets source files and include paths in the parent
> scope.
> > >>> > which would again be another form of maintenance burden because it
> still needs
> > >>> > to figure out which port sources to add etc.
> > >>>
> > >>> W
>> > introducing files like CMakeLists.txt,
> > >>> > I am not sure right now. Extracting the information required by CMake
> > >>> > would
> > >>> > again require scripts to export source files and include paths.
> > >>>
which port sources to add etc.
> >>>
> >>> What about scons, meson, or a plain Makefile for those who
just want to use
> >>> make, then there is GNU make and BSD make, the list is
large? Do we open the
> >>> repo up so
gt;> build system
>>> > >>> like any other piece of code we have.
>>> > >>>
>>> > >>> > First thing I can do is that I split up the patch and extract the
>>> > >>> > CMake
>>> > >>> > spec
gt;>> build system support is written in a clearly defined portable
>>>> > >>> language with
>>>> > >>> power helper libraries. We can run code formatters on our build
>>>> > >>> system, have
>>>> > &g
34 matches
Mail list logo
