Hi Chris,
Thanks for your concerns and advice. I think it is good enough to keep our current method for the C++ client, namely using CMake for the build and using Maven to call CMake and do the packaging. However, things are going to be tough this time since we are not building clients that are simply wrappers of the generated Thrift code. We are going to provide a fully functional TsFile library, which should have write, read, and schema interfaces logically identical to those of the Java version. The library is especially (and maybe only) meant for embedded systems, where advanced features like class, intelligent point, or generic types in C++ may not apply. This also limits the use of third-party libraries greatly, as you have suggested. Fortunately, the TsFile has been well-designed and implemented in Java, so the whole thing is possibly merely a code translation (a massive one, though). Unfortunately, we have very limited experience in primitive C programming. I assume we will probably struggle to make an available version for months. I think we might need your help to check whether the code can work well in an embedded system. Best regards, Tian Jiang At 2024-04-15 21:50:36, "Jialin Qiao" <[email protected]> wrote: >Hi, I support one large maven build, and manage each in their own. > >Jialin Qiao > >Christofer Dutz <[email protected]> 于2024年4月15日周一 20:51写道： >> >> Also, should we probably decide on how to build the project and how to >> structure the sub-modules. >> >> Here, I would also like to propose using what we have in PLC4X, as getting >> such a build to work is quite challenging and we’ve already managed to >> integrate building the following languages in our build: >> >> >> * Java >> * Go >> * Python >> * C >> * C# >> * Rust >> >> The core principles we tried here, is to have one large maven build, that is >> able to build all parts in one big reactor, but that each of the >> sub-projects feel natural for developers in their particular languages. >> >> So, we use IntelliJ for developing the java parts, GoLand for the go part, >> CLion for c, Raider for c#, PyCharm for Python, … also some people use >> VSCode this way. >> >> As there are multiple ways of building C stuff, we decided to use CMake as >> this seems very portable for Win, Mac and Linux. We should also try to stay >> clear of requiring boost for the C-related parts as this complicates the >> build a lot and having something that relies on core C is a lot more >> portable, especially with respect to porting it to run on PLCs directly. >> >> For Rust we use the build in cargo stuff, for Go also the built-in stuff. >> For python I think they use venv in combination with pip3. >> >> Chris >> >> Von: Jialin Qiao <[email protected]> >> Datum: Montag, 15. April 2024 um 12:03 >> An: [email protected] <[email protected]> >> Betreff: Start of TsFile C >> Hi, >> >> To support more scenarios on the edge, we plan to start the C language >> TsFile development, The code will be in the same repo of >> apache/tsfile. >> Welcome to participate in this project :) >> >> Jialin Qiao
