Posts Tagged c/c++
The following content is copied from my weekly report email in gentoo-soc mail list
This year I will work on the libbash runtime project. A short introduction for this project:
Libbash will enable programs to use Abstract Syntax Trees(AST) to parse and interpret *shell* scripts directly instead of using regular expressions. Most of bash 3.2 syntax will be supported. This will be a great benefit to programs both outside and inside Gentoo, including Portage/Paludis and repoman.
For more information, I wrote an introduction explaining its potential usage and benchmark. There’s also a home page for this project. You can find out the rationale, plan and detailed progress there(most content comes from my GSoC proposal).
As the first weekly report, I’d like to briefly talk about our current progress. I’ve been contributing to this project since March , so we have done a lot of things. Here’s a summary:
- Parser grammar improvement
- Build system improvement(C++ hidden visibility, developer flags, gcov, etc.)
- Shell arithmetic
- Variable(string, array) definition and reference
- Variable expansion
- Shell pattern matching
- Compound statement(if, for, while, until, case)
- Shell test expression
- Command execution and substitution
- Shell function
- Several shell built-ins(source, let, etc.)
- Utilities(ast_printer, reimplemented version of Paludis instruo, etc.)
For more detailed information, please visit our home page, my blog or our git repository.
Here are some resources we have:
- CI server(not public accessible yet)
- Agilefant server(for Scrum)
- Test coverage report
- Callgrind and massif target
- Github repository (latest commits)
- Canonical repository (reviewed commits)
- Home page
- #gentoo-libbash IRC channel
Now we can generate correct metadata for 2934 ebuilds(There are 27289 in total). We will get more and more during the summer.
Recently I started working on the libbash project. I will write several articles talking about it in future. Now I’d just like to write something about the problem we encountered during development.
Our project will be a shared library. The C++ visibility support could improve the overall performance. Put simply, it hides most of the ELF symbols which would have previously (and unnecessarily) been public. Well it’s good for the library, it’s not good for unit tests(namely gtest) because they need to know the symbols.
Of course we don’t want the unit tests to be part of our library. So we need to find some way to let the unit test know the symbols and separate them into different automake targets. Our first solution is to use hidden visibility for the library and create an internal target with default visibility for the unit test. However, that requires compiling the source code twice. Finally Petteri Räty come with a solution (He is too busy to write a post :P):
lib_LTLIBRARIES = libcppbash.la
libcppbash_la_SOURCES = blah
libcppbash_la_CXXFLAGS = $(AM_CXXFLAGS) -fvisibility=hidden -fvisibility-inlines-hidden
cppunittests_SOURCES = blah
cppunittests_LDADD = libcppbash.la $(GTEST_LIBS)
cppunittests_LDFLAGS = -static
Here’s his explanation:
libtool by default builds both a shared and a static library for our project. This is why you see it building things twice (with PIC and without). Giving -static to libtool is just telling it to use the static version. Using the static version means everything ends up in the unit test binaries.