[RSB] port graphic libraries into rsb

[Pavel Pisa]

Hello Qiao Yang

On Tuesday 21 of July 2015 14:21:07 QIAO YANG wrote:
> Hi Pavel Pisa,
>
> On Jul 19, 2015, at 10:35 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> > Hello Chris and Qiao Yang,
> >
> > On Monday 20 of July 2015 01:12:33 Chris Johns wrote:
> >> On 20/07/2015 6:55 am, QIAO YANG wrote:
> >> > I've ported the graphic libraries into rsb so that we can build them
> >> > much easier. All Build passed, tested on arm with raspberrypi and i386
> >> > with pc386.
> >>
> >> Fantastic and thank you.
....
> >
> > I use system wide prefix for my RTEMS install. When I specified that
> >
> > --prefix=/opt/rtems4.11
> >
> > When I specified that to sb-set-builder then it silently skips install
> > steps. This leads not only to problem that I have not received resulting
> > binaries (even not found them in temporary RSB trees) but even build of
> > later packages dependant on previous ones failed.
> >
> > I resolved that by use of RSB option
> >
> > --pkg-tar-files
> >
> > tar files has been generated and I could extract content to the right
> > directory and continue build with followup with sucesfull Microwindows
> > package build. I have been able to use that (after tar extraction)
> > to build and run my graphic application in QEMU then.
>
> So the library works if I've got it right. No problem with the build
> process.

The libraries are configured properly. Only thing to solve for you
is to find way how to limit all/as most as possible files installed
in improper directories. It is not fatal but can make troubles
and is misleading. Look for packages options --disable-test, samples
and some related options to direct install of support files to BSP
specific directories. Documentation can go to RTEMS prefix and shared
area. But includes, libraries, binaries and configs should not.

The other issues are for discussion with Chris Johns
and he woks on these. So rebase of your work onto
his newer RSB versions should help.

I have some more things for Microwindows. It seems that
Microwindows mainline (https://github.com/ghaerr/microwindows)
moves forward (commits by georgp24).

You are using alex-sever-h fork. I do not expect that he returns
to the project. We should consolidate code. I have his changes
in my fork. Some of these are not appropriate for mainline
some needs cheanup. But we should move closer to mainline.
As I find time, I try to prepare branch with changes suitable
for mainline. I would like to change Microwindows RTEMS config
and makefiles such way that NOKBD and NOMOUSE can be selected
for RTEMS by config. Same for some screen variants.

So the patches removing keyboard and mouse in Makefiles would
not be required. All things should be controlled by config.

> > Because libraries build is specific than I expect that all build
> > results should be installed in BSP directory, i.e.
> > /opt/rtems4.11/i386-rtems4.11/pc686/{lib,bin,lib/include} in my case.
> > It seems that JPEG library is configured right. But there are significant
> > leakages from freetype, libpng, t1lib and libtiff to
> > "/opt/rtems4.11/bin" and "/opt/rtems4.11/share" directories.
> > t1lib even installs to /share/t1lib directly.
>
> Do you mean that the libraries are not installed in the bsp dir?

Yes and no, libraries required to build RTEMS applications are installed
in the right place but there is significant level of noise - tools,
scripts etc installed in inappropriate places.

Add --pkg-tar-files RSB option and then you can easily see what
is content of each installed package - I hope, that it is 1:1 to what
is really installed/copied to the filesystem.

> In fact, 
> I've got all libraries installed in the right place. Firstly, I doubt if
> the bsp pc686 exists in arch i386. I can only find pc386 in mainline. Make
> sure that the bsp name is correct. Secondly, verify the path you passed is
> what the builder expects as chris explained. I haven't  found out why the
> JPEG works while others can't, but I do use the paths to determin where to
> install.

RTEMS supports boards variants. This means that there are more boards
supported than only these seen as individual subdirectory of each
CPU architecture (these subdirectories are more or less equivalent to
machine or platform on Linux). The varinats usually differ in the compiler
flags and some defines which control source builds.

See

  rtems/c/src/lib/libbsp/i386/pc386/make/custom

There are varinats
  edison.cfg  pc386.cfg  pc486.cfg  pc586.cfg  pc586-sse.cfg
  pc686.cfg  pcp4.cfg

where pc686.cfg includes common pc386.cfg base but selects
pentium generation corresponding optimization
 CPU_CFLAGS = -mtune=pentiumpro

and variant name for RTEMS
 RTEMS_CPU_MODEL=pentiumpro

> I followed alan's blog to setup my environment.
>
> alias i386-kernel-configuer='cd $HOME/development/rtems-386/rtems-git/; \
>     ./bootstrap; \
>     mkdir $HOME/development/rtems-386/build-rtems-386/; \
>         cd $HOME/development/rtems-386/build-rtems-386/; \
>         ../rtems-git/configure --target=i386-rtems4.11 \
>             --enable-rtemsbsp=pc386 \
>             --enable-tests=samples \
>             --enable-networking \
>             --enable-posix \
>             --prefix=$HOME/development/rtems-386/bsps/4.11'
>
> So in my case I've got a directory 'build-rtems-386' and a directory 'bsp'
> . What I passed to sb-set-builder is the directory:
> --prefix=$HOME/development/rtems-386/bsps/4.11, the same path used for
> kernel configure.
>
> The libraries should be finally installed into directories
> $HOME/development/rtems-386/bsps/4.11/pc386/lib
> $HOME/development/rtems-386/bsps/4.11/pc386/lib/include
> $HOME/development/rtems-386/bsps/4.11/pc386/bin
>
> I hope this may help. Tell me if I misunderstood anything.

Great to document for others but there should not be and most
probably is not difference for my setup. So I think that
you should see utils spread to the same places as I have noticed.

Best wishes,

             Pavel