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 <chr...@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 >
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})
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel