Hello Chris, I have written the scripts to build littlevgl using rtems_waf. The build works fine and installs the required header and the static library in the prefix library path.
The repository is pushed here, please have a look: https://github.com/thelunatic/littlevgl-rsb Thanks, Vijay On Tue, Aug 27, 2019 at 1:19 AM Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > > > On Mon, Aug 19, 2019 at 4:26 AM Chris Johns <chr...@rtems.org> wrote: > >> On 18/8/19 2:45 am, Christian Mauderer wrote: >> > On 17/08/2019 18:05, Vijay Kumar Banerjee wrote: >> >> >> >> >> >> >> >> On Thu, Aug 15, 2019 at 3:46 AM Chris Johns <chr...@rtems.org >> >> <mailto:chr...@rtems.org>> wrote: >> >> >> >> On 15/8/19 2:07 am, Vijay Kumar Banerjee wrote: >> >> > I wrote a patch for lv_drivers repository to support FreeBSD >> >> framebuffer >> >> > in fbdev, which they merged to the master today. >> >> >> >> Well done, that is great. >> >> >> >> > I have tested >> >> > the driver to be working with an app that I wrote on FreeBSD and >> >> > tested it on Beaglebone black image 12-STABLE. >> >> >> >> Awesome. >> >> >> >> > I intend to write an RSB recipe to build littleVGL and seek some >> >> guidance >> >> > on how to proceed. :) >> >> >> >> Please review >> >> >> https://docs.rtems.org/branches/master/user/rsb/third-party-packages.html >> >> >> >> I suggest you see how the curl package is done. It is a nice clean >> >> example. >> >> >> >> The packages are sort of based on the FreeBSD ports layout. >> >> Littlevgl is not a >> >> port so we can use `graphics/littlevgl`. >> >> >> >> The file pattern used in the RSB for a 3rd party package is: >> >> >> >> - A buildset or bset file, this is the top level wrapper for the >> >> config files >> >> and selects the version to be built... >> >> >> >> >> https://git.rtems.org/rtems-source-builder/tree/rtems/config/ftp/curl.bset >> >> >> >> - The version specific config file that sets the version and >> >> checksum for the >> >> package. It includes the build config or recipe... >> >> >> >> >> https://git.rtems.org/rtems-source-builder/tree/rtems/config/ftp/curl-7.65.1-1.cfg >> >> >> >> Note, this is a 3prd party package so includes `rtems-bsp.cfg`. >> This >> >> create a >> >> suitable environment to build a package for a BSP. >> >> >> >> - The build config file ... >> >> >> >> >> https://git.rtems.org/rtems-source-builder/tree/source-builder/config/curl-1.cfg >> >> >> >> Hi, >> >> >> >> I have some doubts regarding the build. >> >> The lvgl needs two directoried, lvgl (main) and lv_drivers (for the >> >> driver). And on >> >> top of both, there needs to be two header files to configure the >> >> library, lvgl_conf.h >> >> and lvgl_drv_conf.h . These conf headers are supposed to be edited by >> >> the user >> >> to set the options. >> >> Enable all the features. A user with tight memory needs will need to >> customise >> the config and so handle littlevgl themselves. >> >> > Do we want to build both the directories >> >> separately? >> >> I think together. I have not tried to build the various hardware drivers >> the >> package provides. If a driver builds with RTEMS then I suggest we build >> them. If >> they need special config file settings it will be harder to do and I >> suspect we >> cannot build them. >> >> >> Or do we >> >> want to create our own directoy and put both driver and other stuffs >> in it? >> >> We may but that is something we look at later. >> >> >> >> >> Also, lvgl doesn't have its own makefile, so we have to write our own. >> in my >> >> application, I included the .mk file in my app's makefile and added the >> >> build recipe >> >> for it. How do we want to handle this in RSB? >> >> I suggest we build the package using rtems_waf. It is the only clean way >> we >> currently have to get the needed BSP ABI build flags. >> >> Could a git repo be created where littlevgl and rtems_waf are submodules? >> >> Hi, > > Sorry for the late reply, I had to visit home and didn't get much time, so > I decided > to do it out of GSoC. > > I started the repo as you suggested and it's in the initial state. The > repository is > pushed in GitHub here: > https://github.com/thelunatic/littlevgl-rsb . > > I'm starting to write the wscript for the repo by taking reference from > your script below > to get the file sources. > >> To get hold of the sources to build I am using a script that creates a >> Makefile >> that runs and outputs the list of source ... >> >> ----------- >> #! /bin/sh >> >> set -e >> #set -x >> >> cd $(dirname $0) >> >> cleanup() >> { >> rm -f Makefile.gen >> } >> >> trap cleanup EXIT >> >> cat <<EOF > Makefile.gen >> LVGL_DIR = \$(CURDIR) >> include lvgl/lvgl.mk >> include lv_drivers/lv_drivers.mk >> CSRCS: >> @echo "\$(CSRCS)" >> EOF >> >> excludes="R61581.c SSD1963.c ST7565.c UC1610.c FT5406EE8.c XPT2046.c" >> >> csrcs=$(make -f Makefile.gen CSRCS) >> srcs= >> >> for c in ${csrcs} >> do >> found=no >> for e in ${excludes} >> do >> if [ $c = $e ]; then >> found=yes >> fi >> done >> if [ $found != yes ]; then >> name=$(find . -name $c) >> srcs="${srcs} ${name}" >> fi >> done >> >> # >> # Add something to write littlevgl.py which can be imported in a >> # wscript file >> # >> ------------ >> >> >> If I create an lvgl tar with drivers and library in it, along with a >> >> makefile, will it go >> >> into our ftp server somewhere? Can this be an approach to build the >> >> whole stuff? >> > >> > Hm. Difficult case. We should also take into account that lvgl doesn't >> > necessarily have to use the FreeBSD frame buffer but can use some other >> > displays too. So what you do would be more a "lvgl-libbsd" packet. >> >> It can support any driver, the FB driver is just one. You can use the >> same build >> of the core, draw etc code with any other driver. The user needs to >> register the >> driver functions during initialisation so they can be the FreeBSD FB one >> or >> something else. >> >> In v6 the resolution is set at run time and the conf file are just >> defaults. >> >> There is one issue, the path to the frame buffer is currently hard coded >> in the >> conf file and I would like to change that in littvlg so the path is >> passed in. I >> am not sure how this can be done without breaking the API. Maybe a new >> call. >> >> Another change is to the memory allocator to not loop forever on an >> error. It >> would be nice to register a fault handler that is called. >> >> > If >> > such a packet is created, it should most likely contain everything >> > necessary: lvgl, lv_drivers and the config files (I hope they are not >> > target specific but only display specific?) >> >> I suggest the configuration file enables all features present plus the >> frame >> buffer driver. I am not sure which input drivers to enable. >> >> > Regarding where to put files: RSB can use quite some sources. See >> > >> https://docs.rtems.org/branches/master/user/rsb/configuration.html#source-and-patches >> > >> > If the config and a Makefile can be put into a patch: It's also not >> > uncommon to use patches from the mailing list like that: >> > >> > rtems/config/tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg:31:%patch >> > add gcc -p1 >> > >> https://devel.rtems.org/raw-attachment/ticket/3242/gcc-sparc-ticket-3242-v2.patch >> > >> > I think Chris knows RSB a lot better than me. Maybe he has some better >> > suggestions. >> >> A repo would be nice. We are discussing in another thread related to the >> multiio >> package if that stays as a separate repo and we grow the number we have >> or do we >> create a packages repo and collect it and this as separate pieces? >> >> Chris >> >> > >> >> >> >> These configs do not include any other configs and could be used to >> >> build a >> >> native package for a host or a 3rd party package for RTEMS. >> >> >> >> - The `%prep` section prepares the source to build. For github if >> we are >> >> building from master we select a commit and fetch a compressed >> >> tarball. This >> >> means we can snapshot the source when making a release. The RSB >> can work >> >> directly with the git repo however this has proven to be more >> >> fragile than a >> >> tarball. >> >> >> >> - The `%build` section builds the package. The contents of this >> file >> >> are used to >> >> create a shell script. Use --dry-run, --trace and --log to debug >> what is >> >> happening. The shell script contents should be viewable in the log >> >> file if a dry >> >> run does not created it. There is a lot of trace but searching will >> >> help you >> >> locate the piece you are interested in. The `source_dir_*` shell >> >> variable is the >> >> directory created by extracting the tarfile. The macros >> >> `%{build_directory}` and >> >> `%{host_build_flags}` are defined in `defaults.mc >> >> <http://defaults.mc>` and should handle the >> >> compiler and flags. You may want to check libbsd is installed in >> >> your config, >> >> see ... >> >> >> >> >> https://git.rtems.org/rtems-source-builder/tree/rtems/config/rtems-bsp.cfg#n198 >> >> >> >> .. for an example of how to check and add `%error This package >> needs >> >> libbsd, >> >> please build and install` or something like that as an error. The >> >> paths to >> >> install to are set up for you, these match how a BSP and RTEMS are >> >> installed. >> >> The layout needs to be followed or applications will not be able to >> >> find the >> >> header or the library. >> >> >> >> - The `%install` section installs the package. The install process >> >> is to a >> >> staging area `${SB_BUILD_ROOT}`. Nothing is installed unless all >> >> parts build so >> >> we do not have an inconsistent build in the install prefix. >> >> >> >> Chris >> >> >> >> >> >> _______________________________________________ >> >> devel mailing list >> >> devel@rtems.org >> >> http://lists.rtems.org/mailman/listinfo/devel >> >> >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
