As far as clang is concerned, the toolchain script is simply creating a symlink to the system-installed version. Doing the same for clang++ should work just fine. The main point is to avoid using features that GCC supports but clang doesn't (though it's unlikely you'll even need to consider such a feature, there's not many of those). Ironing out the build system kinks is not as important. :)
-- jzr On 10 October 2017 at 19:09, Jaroslav Jindrák <[email protected]> wrote: > Hi, > > thank you for your replies. As for your reactions: > > 1) Libposix vs native > The C++ standard cites multiple (but not all) ISO C headers. One of the > ideas I had was to have the ones included > in the standard as they are now (in the root include directory as <c*> > headers) and the rest (ipc, fibrils, ...) in an > include/helenos directory (again as <c*>). This would allow us to include > them directly, because otherwise we would > have to use: > > extern "C" { > #include <native_header> > } > > every time we'd need this functionality. I will have to research libposix a > little bit more (at the moment > libposix is an alias to magic for me :), but it should be possible (atleast > for the standard headers) to use the same > libposix macro in makefiles (seeing as the linkage would be specified in the > <c*> headers and the rest should be > identical to linking it in C). Luckily, I opted to not include the headers > into the global namespace and then one by > one use them (using ::NAME) them in the std namespace which does not bound > us to specific API (well, it binds > the application using it, but the libcpp wrapper headers should be usable in > both ways). To be honest I'm not really > sure why libc++ decided to do this as they include the symbols twice in the > global and std namespaces this way. > > As for the question asked by JiriS to my section 6.10: As far as I know, it > does not, because the actual inclusion > of C in C++ really only needs extern "C" {} around the include - the C++ > standard provides those <c*> headers mostly for > convenience (and consistence, as C++ standard headers lack an extension). > > 2) Porting > Originally when I came to MD to discuss the posibility of writing this > thesis, I intended to write the entire > standard library from scratch (the main reason for choosing this topic was > because I wanted to write the > standard library and have a use for that implementation :), but as MD > pointed out, some stuff like containers > and algorithms are mostly template based and would be redundant to implement > them from scratch > (given the limited amount of time I have for this thesis). > > However, one idea I was coining in my head since after that discussion was > to implement the non-STL stuff > from scratch in libcpp (which would allow us to include it in the mainline) > and port the STL in a separate > library that would be part of coastline - and possibly do something similar > to what libustl has done: > provide alternative implementations from scratch for containers which would > meet the standard API but > would be implemented in a simplified manner (e.g. stubs, containers > implemented over vector etc.) and > leave the actual implementation of these modules for a post-thesis time. > (The idea is that programs would > work without using the libc++ STL from coastline, albeit at e.g. worse > speed.) > > 3) Demonstrator > I was mostly meaning what I wrote in the type of if there is a C++ program > that would really stretch the > library (i.e. use most of its features) it tends to be very 3rd party > dependend. However, your answer gave me > the idea of choosing multiple smaller programs (and no, I don't know why I > didn't think of it before :) that > demonstrate different parts of the library (+ unit tests). > > 4) Compilers > Supporting clang should not be that hard as far as I'm not concerned, > cross-g++ is already bundled > in the toolchain script, but adding cross-clang++ should not be a problem > (assuming it's not already > downloaded by the script) and luckily for as (again, afaik) clang++ should > be fully compatible with > g++ expectations of the C++ runtime (clang defaults to it on Linux). I only > mentioned that because > the I'm not very versed in the matter of HelenOS build system (and even the > working of autotool.py, > I hacked the cross-g++ into the parts where cross-gcc is defined for > generated makefiles), but now > that I progressed a bit (that part was written earlier when adding cross-g++ > seemed super hard), it > doesn't seem that complicated to do. > > 5) C++ coding style > I was asking more in the way of the stuff written from scratch using more > C++ coding style, example: > > In HelenOS cstyle, pointers should be declared as follows: > char *c; > However, in modern C++ the (generally, not by all) followed style is (e.g. > used in libc++): > char* c; > Which is because the C style is used for declaring multiple variables at the > start of a function: > char c, *cptr1, cc, *cptr2; > Which is potentially problematic in C++ as simple declaration (and with > default constructor a definition) > can have side effects (constructors). > > 6) Libc++ vs libstdc++ > Since BSD/MIT is more preferred, libc++ would probably be better as it is > licensed under both and > libstdc++ is licensed under GPL. Plus, libc++ has much, MUCH better source > code (i.e. more readable, > with better formatting and mainly more consistent - libstdc++ mixes many > coding styles together). > Also, thanks for the link jzr, that one should come in very handy :) > (Additionally, I'm a huge clang/llvm/libc++ fan!) > > Again, thank you very much for your input :) > > > S pozdravem, > Jaroslav Jindrak > > On 10 October 2017 at 17:37, Jiří Zárevúcky <[email protected]> > wrote: >> >> Hello Jaroslav! >> >> Nice to see someone working on this, and thanks for linking in the ML. >> I can help answer some of the questions. >> >> The state of HelenOS libc and libposix is far from ideal, and it's going >> to >> keep evolving in the coming months. Ideally, libc should eventually be >> compatible with C and C++ standard (if not outright compliant), and >> at the very least not have outright conflicts with the POSIX standard. >> >> Insofar as a subset of C++ library can be viewed as a wrapper for C >> library, I think it would be adequate for that subset's completeness to >> match what's implemented in libc and/or libposix. If you think a part >> of C standard library is needed for your work to be successful, it should >> be >> implemented in libc first (and I'll be happy to review and possibly >> integrate your work). >> >> When it comes to particular implementation, I'd personally prefer >> LLVM's libc++. You should refrain from using GPL-licenced code, >> but BSD and MIT are fair game (so long as you follow their >> requirements). I'm not entirely sure about Apache. >> Also, this page might come in handy: >> https://clang.llvm.org/docs/Toolchain.html >> >> It's in the best interest of maintainability to keep changes from >> upstream code to a minimum. For example, conditional sections >> should not be removed unless it's necessary, and it might be >> better to provide pthreads API implemented using fibrils, than >> to change the caller directly. Currently, libposix has empty stubs >> for pthread API, but having a fibril-backed libpthread as a >> separate library is something I'd like to have. >> >> For compiler support, I'm currently reviving clang (see my latest >> commits to mainline), so if possible, you should strive to support >> cross-gcc and clang. You can safely ignore everything else. >> >> Last, but not least, I'm available most afternoons/evenings on >> our IRC channel, so I invite you to pop in anytime and ask any >> questions. My nickname on IRC is jzr. >> >> >> -- jzr >> >> >> On 10 October 2017 at 16:06, Jaroslav Jindrák <[email protected]> wrote: >> > Hi Martin, >> > >> > I'm sending you a research/progress file I've written so far that >> > documents >> > my progress. >> > It includes information on the things I have already done, possible >> > porting >> > sources, discussion >> > of the portability of the different modules (i.e. standard headers) and >> > section 6 contains a few >> > questions I wanted to ask you (mostly regarding the direction you'd like >> > this thesis to take - if you >> > do have preference). >> > >> > PS. Since HelenOS is a community project, I decided to CC the >> > helenos-devel >> > mailing list in the >> > case somebody else would be interested (or would want to voice their >> > preference in the matters >> > discussed). (Although I'm not sure how that'd be incorporated into the >> > thesis.) >> > >> > If you prefer to meet in person to discuss this, let me know and I'll >> > come >> > to MS. >> > >> > S pozdravem, >> > Jaroslav Jindrak >> > >> > _______________________________________________ >> > HelenOS-devel mailing list >> > [email protected] >> > http://lists.modry.cz/listinfo/helenos-devel >> > > > _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
