On 11 May 2018 at 19:20, Jakub Jermář <[email protected]> wrote: > [...] > > Other topics: > > - JZr is planning to remove HelenOS linker scripts in favor of > compiler-provided ones > - there is a catch though: for some platforms also the > compiler-provided linker scripts must be patched, so it will become > completely impossible to use HelenOS a compiler not built using our > toolchain script (now it is _only_ unsupported, but still possible if > one is lucky) > - VH: how about importing the compiler-provided linker scripts to > HelenOS then? >
The boon of using the default linker scripts is that the correct one is automatically selected for every combination of linker options. Currently, we select one manually in the makefiles, which is not a big problem, but it adds unnecessary complexity to the build scripts. As for using the native linux toolchain for building HelenOS, I fail to see the advantage. It prevents using libraries and headers trivially provided with the compiler itself, and anyone who actually tries to build an OS this way is doing it wrong. As I see it, the argument here is "It is unsupported, almost guaranteed to result in a broken system, but we should make sacrifices to not prevent people trying." > > - JJ brought up a topic "how to improve the community experience" > > - should more people be on IRC? > - VH: would rather got rid of IRC completely, but uses it anyway > - JS: said he would try to hang out in #helenos regularly, if only > he can setup his IRC client properly > - JJ: is fond of using IRC > JZr: prefers IRC to mailing list, and wishes more people were using it. Possible alternative: https://gitter.im ? > > - shall we switch from Trac to GitHub issues? > - People did not show extra emotional attachment to Trac > - JJi suggested that reportedly GitHub issues are difficult to > export, should we want to leave in the future > - VH suggested we setup a GitLab instance in the future > - JJ said that should we start self-hosting helenos.org, we would > most likely need to switch to a statically generated web and move the > wiki and tickets somewhere else anyway > I like GitHub issues. They are simple, easy to use, and most people trying out HelenOS already have an account. As for the difficulty of exporting, a quick search shows that GitHub has an API for that. A self-hosted GitLab instance would have most of the same problems that our current Trac has. For the replacement of our current web, static pages generated from git-versioned markdown sources seems to me the ideal solution. github can easily provide the infrastructure for that. > - shall more communication go to the ML? > - people seemed indifferent, but complained about too much GH PR > e-mail traffic (too much of it, sometimes happening too quickly) > - JJ: let's forward all important communication (commits, tickets, > travis) also to the ML, so that people who are not subscribed see that > somebody is working on the project > - people on IRC asked: > > - "What would be the best way to learn about HelenOS" > - JJi confirmed that newcomers can have difficult times getting > familiar with HelenOS > - JS suggested creating more blog-like material and providing > skeletal documentation on subsystems with one or two sentences for each > > - "Where is HelenOS going" > - JJ: might be difficult to agree on because different people may > have different ideas and a) we cannot tell people what to do b) he/she > who merges existing code is more right than he/she who doesn't > - JS: mentioned a minimal common direction (something which the > scribe forgot (JS?) and experimenting) > My current direction could be said to be providing a solid foundation for other work. In the past, HelenOS went too much in the direction "let's reinvent all the wheels". That's a reasonable approach if a foundation already exists, but not an excuse to completely lack a body of functionality that already stands implemented, that we have no replacement for. I'd rather spend time trying new things than implementing what has been done dozen times over. > - Doxygen > - current state is not good, if built automatically on > ci.helenos.org the result would be dissatisfactory > - VH: need to be able to break documentation for the individual > components into Doxygen modules > - JS: in the future Sycek could check that a function is documented > > On 05/04/2018 04:25 PM, Jakub Jermář wrote: >> Hi! >> >> The 98th HelenOS project meeting will take place on Thursday of May >> 11, shortly after 18:00 somewhere in Prague, Czech Republic. Please let >> me know whether you plan to come so that I can make a reasonable >> reservation, no later than by morning of May 9. Also, do let me know >> whether you have any preferences for the venue of the meeting. >> >> Jakub >> >> _______________________________________________ >> 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 _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
