Building RTEMS hello world image using CMake
Sambeet Panigrahi
sambeet161616 at gmail.com
Mon Mar 14 23:59:24 UTC 2016
Hi,
Sorry for the delay. I am attaching my CMakeLists.txt with this.The test.c
is the source code from examples-v2. I created a separate build folder to
hold the builds. And from inside that gave the command
$ cmake ..
and then for the generated makefile,I gave the command
$ make all
After the executable was created,I used the simulator to get the output
$ $HOME/development/rtems/4.11.0-rc1/bin/sparc-rtems4.11-run ./HELLO
And then I got the ouput as
*** MODIFIED HELLO WORLD TEST ***
Hello Sambeet!How are You?
*** END OF MODIFIED HELLO WORLD TEST ***
On Mon, Mar 14, 2016 at 5:14 AM, Chris Johns <chrisj at rtems.org> wrote:
> On 14/03/2016 09:33, Pavel Pisa wrote:
>
>> Hello Chris and others,
>>
>> On Sunday 13 of March 2016 22:28:14 Chris Johns wrote:
>>
>>> On 13/03/2016 1:53 AM, Gedare Bloom wrote:
>>>
>>>> If this works for you, and you are sufficiently interested, it would
>>>> be useful to provide CMake example for the examples-v2.git repository
>>>> for others to benefit.
>>>>
>>>
>>> I am not sure about adding this to examples-v2.git. I would prefer it to
>>> be a waf only build system. I am not sure if make support is still
>>> present and working but it will go once Makefile.inc goes as it is not
>>> supported in the new RTEMS waf build system.
>>>
>>
>> please, consider to keep/add some mechanism, rule etc.
>> to export Makefile.inc equivalent content to some file
>> in /opt/rtems/arch/bsp directory in easily readable form
>> (make, shell assignments or some other sed parsable format).
>>
>
> We have discussed this before in detail. I refer you to the thread from
> October last year ..
> https://lists.rtems.org/pipermail/devel/2015-October/012659.html.
>
> I could try to find how to do that when I find time to
>> switch to 4.12 and WAF. I think, that it is so minimal
>> information and it worth to be archived/documented with
>> installed BSP anyway and if it is in easily readable form
>> then it is better.
>>
>
> The project as a whole needs to address this issue in a robust method and
> what is made available as an interface for make file based applications
> should be the same interface for waf, cmake, scons, nmake, jam, or even a
> hand written batch file on Windows (haha).
>
> I see future when this information is not stored and easily
>> readable from installed libraries tree, as a real problem,
>> so I vote to not cut support for other make systems
>> for applications.
>>
>
> RTEMS installs many files that are not human readable, for example all
> library archives and tools, (nm, readelf etc) are provided to examine them.
> The problem with easy to read files and exposing this type of information
> is users not using the provided API and then being disappointed when the
> format changes. Being able to easily access and review the information
> installed is important, it maybe via a provided tool.
>
> How you propose to maintain for
>> example Microwindows and other libraries in future?
>>
>
> https://lists.rtems.org/pipermail/devel/2015-October/012666.html
>
> Being able to build a make based application is not going away. What RTEMS
> uses to build itself is the domain of the RTEMS kernel and should not
> effect any user application in anyway. We could decide to build RTEMS using
> manually edited Power Shell batch files only on Windows and a user's
> application should not notice.
>
> Makefile.inc is broken because it exports internal information we cannot
> control and maintain and we have no choice in what we do. We cannot state
> these leaking internal makefile fragments are now part of the formally
> exported API and we cannot determine what users have used on purpose or by
> accident. We can only create an API and move forward and address specific
> user issues as they arise. The key issue internally in RTEMS with the BSP
> .cfg files is the wide variations of how things are done and it is this
> that exported. I suspect most BSP developers never considered what they did
> in a BSP deep in RTEMS was visible to user applications and nor should they
> have needed too.
>
> The other important fact is not all users use make or Makefile.inc because
> it is only usable in make based application. I am one because Makefile.inc
> is inherently broken and leaks uncontrollable details into applications.
> This means for a long time, and I would say easily over 10 years RTEMS has
> left other build systems users out in the cold. This needs to end and we
> need to provide support for all possible build systems.
>
> If these libraries are rewritten to WAF build then
>> each time when mainline is changed it would require
>> to analyze and update WAF based fork. May it be that
>> it stay to be solved by RSB. But again forcing every project
>> and application to be build through RSB is not win either.
>>
>
> <sigh> This is not what is being stated and it never has. Please do not
> confuse the fact the examples-v2 is using waf as a statement that all RTEMS
> applications _must_ be built with waf. The whole point of offering the idea
> of a separate repo dedicated to _all_ builds system is to collect this
> information and provide some sample code built in different ways. Here is a
> link to the up coming RTEMS User Manual's comment on Open Source ..
> https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/overview/index.html#open-source.
> The last paragraph is true for all parts of a user's project including
> build systems.
>
>
>> Some mechanism to build Automake and Autoconf based projects
>> should to be considered as well or option to build broad range
>> of POSIX compliant packages against RTEMS would be complicated
>> too. I do not use Autoconf/Automake for RTEMS projects now
>> but it is thing which should be taken into account.
>>
>> From my projects perspective, it would be real problem
>> to rewrite set of my projects which contains consistent
>> build system over many git submodules where many libraries
>> and even whole application compile to Linux userspace, Linux kernel,
>> RTEMS, Windows and many bare metal targets. I have about 30
>> automake-like fragments which are over 20kB long in my
>> largest project build for RTEMS. It needs to be maintained
>> for RTEMS-4.10 for long time due testing and instrument certification
>> but I want to keep run it against RTEMS development version
>> to catch problems and regressions in time. When I rewrite
>> all that fragments to the WAF then I have to keep WAF
>> in sync with other stuff which counts hundreds (may it be 500)
>> such make fragments and their total length is in hundreds kB.
>> So thinking about rewrite and forking is really nightmare
>> dream for me. For sure, I would look how to implement some hack
>> to extract required information to file as I do for Linux modules
>> build for example but it is not ideal solution.
>>
>
> I understand. I cannot say what is offered will be 100% suitable yet, I
> suspect you need to make some changes. What I would like to offer is the
> hope these changes will be once, this is the intended aim.
>
> So I hope and vote for some Makefile.inc alternative
>> to be available even in future RTEMS versions.
>>
>
> If course, and I would like to further extend the requirements to say that
> the interface used remains stable across future RTEMS releases and stable
> across all BSPs and architectures supported by RTEMS in a release. We
> currently cannot meet this requirement.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160315/6c28e397/attachment-0001.html>
-------------- next part --------------
cmake_minimum_required(VERSION 2.8.11)
set(RTEMS_ROOT_PATH "/home/sambeet/development")
set(RTEMS_TOOLS_INSTALL_DIR "${RTEMS_ROOT_PATH}/rtems/4.11.0-rc1")
set(RTEMS_TOOLS_BSP_LIB_DIR "${RTEMS_ROOT_PATH}/4.11.0-rc1/sparc-rtems4.11/lib")
set(RTEMS_KERNEL_INSTALL_DIR "${RTEMS_ROOT_PATH}/b-sis")
set(RTEMS_KERNEL_BSP_LIB_DIR "${RTEMS_ROOT_PATH}/b-sis/sparc-rtems4.11/sis/lib")
set(ENV{PATH} "${RTEMS_TOOLS_INSTALL_DIR}/bin:$ENV{PATH}")
set(RTEMS_TOOLS_BSP_INCLUDE_DIR "${RTEMS_TOOLS_BSP_LIB_DIR}/include")
set(RTEMS_KERNEL_BSP_INCLUDE_DIR "${RTEMS_KERNEL_BSP_LIB_DIR}/include")
set(RTEMS_COMPILE_OPTIONS "-B${RTEMS_KERNEL_BSP_LIB_DIR} -B${RTEMS_TOOLS_BSP_LIB_DIR} -specs bsp_specs -qrtems -mcpu=cypress")
include(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR sparc)
CMAKE_FORCE_C_COMPILER ("/home/sambeet/development/rtems/4.11.0-rc1/bin/sparc-rtems4.11-gcc" GNU)
if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "")
endif()
set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS Debug RelWithDebInfo Release)
set(CMAKE_C_FLAGS_DEBUG "${RTEMS_COMPILE_OPTIONS} -g" CACHE STRING "")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "${RTEMS_COMPILE_OPTIONS} -g -O2" CACHE STRING "")
set(CMAKE_C_FLAGS_RELEASE "${RTEMS_COMPILE_OPTIONS} -O2 -DNDEBUG" CACHE STRING "")
project(hello)
add_executable(HELLO test.c)
target_include_directories(HELLO BEFORE PRIVATE
${RTEMS_TOOLS_BSP_INCLUDE_DIR}
${RTEMS_KERNEL_BSP_INCLUDE_DIR})
More information about the devel
mailing list