Opened on 03/08/11 at 07:01:49
Closed on 12/18/14 at 09:47:16
#1758 closed defect (invalid)
RTEMS Makefile templates include paths screwed up
Reported by: | Sebastian Huber | Owned by: | Ralf Corsepius |
---|---|---|---|
Priority: | normal | Milestone: | 4.11 |
Component: | build | Version: | 4.11 |
Severity: | normal | Keywords: | |
Cc: | joel.sherrill@…, thomas.doerfler@…, chrisj@…, dufault@… | Blocked By: | |
Blocking: |
Description (last modified by 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.
Change History (7)
comment:1 Changed on 03/08/11 at 08:02:57 by Ralf Corsepius
Summary: | Standard Makefile support is broken → RTEMS Makefile templates include paths screwed up |
---|
comment:2 Changed on 03/08/11 at 10:40:42 by dufault
Cc: | dufault added |
---|
comment:3 Changed on 03/08/11 at 14:58:21 by Joel Sherrill
Cc: | Joel Sherrill added |
---|
comment:4 Changed on 03/08/11 at 16:19:06 by thomas.doerfler
Cc: | thomas.doerfler added |
---|
comment:5 Changed on 03/08/11 at 23:30:25 by Chris Johns
Cc: | Chris Johns added |
---|
comment:6 Changed on 11/24/14 at 18:58:28 by Gedare Bloom
Version: | HEAD → 4.11 |
---|
Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11
comment:7 Changed on 12/18/14 at 09:47:16 by Sebastian Huber
Description: | modified (diff) |
---|---|
Resolution: | → invalid |
Status: | new → closed |
The examples use now waf instead of make.
Note: See
TracTickets for help on using
tickets.
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:
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.
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.
Fair enough. This is a big task when you include all that depend on it plus the documentation changes needed.
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.
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.
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: