[Bug 1758] RTEMS Makefile templates include paths screwed up

bugzilla-daemon at rtems.org bugzilla-daemon at rtems.org
Wed Mar 9 00:30:28 UTC 2011


https://www.rtems.org/bugzilla/show_bug.cgi?id=1758

Chris Johns <chrisj at rtems.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chrisj at rtems.org

--- Comment #12 from Chris Johns <chrisj at rtems.org> 2011-03-08 18:30:25 CST ---
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.

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply 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]

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the bugs mailing list