RTEMS Makefile templates include paths screwed up

[Sebastian Huber]

With the current CVS head, I cannot build the RTEMS examples:

sh@cosinus:~/cvs-rtems-examples > export RTEMS_MAKEFILE_PATH=/opt/rtems-4.11/sparc-rtems4.11/sis
sh@cosinus:~/cvs-rtems-examples > make
/opt/rtems-4.11/make/custom/sis.cfg:7: /opt/rtems-4.11/share/rtems4.11/make/custom/erc32.cfg: No such file or directory
make: * No rule to make target `/opt/rtems-4.11/share/rtems4.11/make/custom/erc32.cfg'. Stop.

[Chris Johns]

Can we please keep the tone of posts in this PR civil ? It is good to see the history documented how-ever the tone is unfortunate. This is one of the oldest parts of RTEMS so a little longer while we discuss and I hope agree on a path forward should not be too difficult.

It seems things have broken and that is something we need to avoid. There is heat in this topic and given there are commits happening with no clear agreed path forward people will be upset. There are 2 aspects, the management of any *agreed* change, and the technical solution. From a management point of view we need to have a working build system for things that use the Makefile includes and BSP config files what-ever this is.

Replying to comment:11:

Replying to comment:10:

Replying to comment:9:

I am sure you have a mechanism in mind to ensure
the application is built with the right libraries, compiler settings etc.

Basically like you would build any other arbitrary package on any other
arbitrary OS: From manual input, using your preferred tools, being assisted by
standardized tools (e.g. pkg-config support files).

The fundamental difference would be that you are not being forced to struggle
the fragments and don't have to fight with them (e.g. when default.cfg pulls in
gcc-target-default.cfg which will kill most configure scripts).

Let me provide an example to get you rough feeling for where I am heading to:
# make RTEMS_BSP=sis
# make install
# export PKG_CONFIG_PATH=/opt/rtems-4.11/lib/pkgconfig
# pkg-config --cflags sparc-rtems4.11-sis
-qrtems -B/opt/rtems-4.11/sparc-rtems4.11/lib/
-B/opt/rtems-4.11/sparc-rtems4.11/sis/lib/ --specs bsp_specs -mcpu=cypress -O2
-g -Wall -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs

cd <myapplication>
./configure CFLAGS=$(pkg-config --cflags sparc-rtems4.11-sis) ....

[Note: This is with a real current rtems-4.11 source tree,
Things are broken and arguable in detail, but the basic already work]

OK. So you want to move forward with the pkgconfig stuff. I thought you had
misgivings about it at one point.

I am not sure about pkgconfig. I suspect this is due to my lack of familiarity with it. If this is the case for me then the concern for a new user is even higher because they also have RTEMS as something new. I also feel we have not explored other solutions enough to discount them.

For anything to be accepted and anything added to CVS I would like to see stand alone hello type application. PR with patches or a tarball and posts to the user list are fine.

What about getting from ELF to downloadable format? That is beyond the scope
of pkgconfig AFAIK

This is an issue to be resolved. A quick check of shows only a hand full of BSPs that are not the default bsp post link command. In the one I checked (mcf52235.cfg) it is just a strip. Do we really need a post link phase any more ? I suspect not and if needed it could be a BSP specific script.

I really don't care except that at this point we need the legacy makefile
adapter in place until the use cases are converted to autotools.

Fair enough. This is a big task when you include all that depend on it plus the documentation changes needed.

If Chris has

this ready for the examples-v2 and network-demos, then it needs to be committed
ASAP.

I have only converted rtems-testing. I have not converted anything else. Until the .exe is removed autotools and any other solution is going to have to hack around this issue.

We should move all examples and samples to autoconf and automake. This is the standard build system for RTEMS and therefore we should make it the standard build system for examples, tests and applications. It is the only build system we provide with our tools and we keep it up to date. There is only one problem with using autoconf and automake...

..we need to resolve the name of the RTEMS executables. The default executable is a configuration item in ld. It is used by autoconf to set 'EXEEXT' and '$(EXEETX)' is part of all the automake rules. To create a .exe file using automake you need to provide the rules and in the end you do all the work automake is suppose to do. You might as well just write a plain Makefile. If we really do want .exe for all linker output we should change ld. I do not like the .exe being used.

I can probably get rtems-graphics-toolkit and rtems-addon-packages working
again since they are probing. Chris and I can hopefully get the ada-examples
working again together.

My work on the stand alone applications that build using autoconf and automake show the build system and the exporting of BSP information from RTEMS are separate things. My work showed this how-ever we need to sort out a few things before this. For example we need a set of standard m4 macros as a packages for a user to take and use. We also need a bootstrap script. This needs to be placed in CVS and documented.

The PR is turning into being about removing the linkage between the BSP configuration information and the build system. At the moment the BSP information and the way to build are the same thing and this is confusing, limiting to those who wish to use other build systems, and a maintenance issue inside RTEMS.

There is also the use case of the gcc-testing support. We will not be
reporting tool results until some temporary legacy Makefile adapter is in place
OR the uses are converted to pkgconfig.

I really would have preferred to have these use cases switched to pkgconfig and
autotools as appropriate before the legacy support went away.

I have been looking at the issue of the BSP configuration files. I have looked at the issues of using autoconf and automake and it does work (with patches to remove the .exe issue). I see Ralf's point of view that exporting this information is broken but I am not sure we need to stop doing it. We are an RTOS that always builds on host machines and exporting this information may be a suitable solution. A BSP does need to do this at some level, be it a document, README or configuration file.

My understanding on exporting BSP configurations being broken can be described with the example of giving you a shell to a Linux machine you are remote to that you know nothing about and asking you to build a sample program so it executes the fastest it can by setting CFLAGS. You will inspect the CPU type, look at the code you wish to run and then select the flags to be used. What you select has nothing to do with the flags used to build the kernel, the C library or any other part of the system you are running on and nor should they. So why do RTEMS application need to ? They do not ....

... but it helps. In the Linux example gcc will read the built in specs file or the host specific spec file and that describes how to the create an executable. All executables running in user land will be the same. With RTEMS this does not happen. A sparc-rtems4.11-gcc compiler can make a different executable image for every BSP. This means we need a way for the user to get at this information.

I do not have a solution but I have a few ideas that need to be explored.

The first possible solution is to look at the gcc specs files and to see if the information currently in the BSP configuration files that really matter can be moved to into specs files. If this can be done I think it would be a nice solution. To do this I suspect we internally in RTEMS we would need to take the BSP specific details and generate a specs file only because they are easy to get wrong.

A second solution which may work is to provide a wrapper script in the RTEMS directory for gcc. Something like:

$ rtems-gcc sparc sis [gcc options]

[Gedare Bloom]

Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

[Sebastian Huber]

The examples use now waf instead of make.