I would propose a trivial criteria for the required C language feature set: a _complete_ operating system distribution must compile and become bootable as first priority with whatever tinycc was capable to compile and link already. That's mostly C99 excluding complex data type currently (which can be implemented outside compiler and libc).
The following package set passed completely with tinycc already: http://tinyfront.mooo.com/downloads/x86-embedded/666666/tinyfront-packages.list The userspace-fork is discussed here: http://tinyfront.mooo.com/docs.html#Userspace-Fork TinyCC kernel support is published already. In this regard TinyCC would not need further C11 extensions implemented, and i would propose to keep in mind acceptance criteria outlined with regards to standards compliance: http://tinyfront.mooo.com/docs.html#Acceptance-Criteria Once temperatures cooled back down i'll get back to the tinycc-compiled bash.static bug to retain the whole system-integration self-hosting with the i586-tinycc-linux2-musl.iso system. That's one major blocker remaining to cope with before uploading the devdrop. It's much easier if development could be coordinated with a common baseline distribution and the fully forked portage tree maintained within git, and _all_ development utilities being available, self-hosting with tinycc i mean. Focus on C11 itself opens a can of worms i rather not touch myself, which was one reason why i've patched linux-5.9 and finally forked away everything. One such C11 related problem was outlined in the kernel section here: http://tinyfront.mooo.com/docs.html#Kernel Long story short, except for some bugs and quirks, tinycc already got all features implemented which were necessary to compile an extended set of packages of mostly most recent software versions. Anyway, that's my 2cents from the system integration perspective of a complete(!) tinycc driven operating system. Regards On 2025-08-09 11:16, david.k...@libertysurf.fr wrote: > For known bugs, yeah. > > But as stated before, first and foremost is to set a goal. > > 1- What should be present in the 1.0.0 release ? > > Full C99 or C11 support ? C11 is safer and more "up to date" : > > https://web.archive.org/web/20200806193736/https://smartbear.com/blog/test-and-monitor/c11-a-new-c-standard-aiming-at-safer-programming/ > > Hence C11 should be getting way more prevalent in the existing source code > out there : > > https://www.geeksforgeeks.org/c/c-programming-language-standard/ > > 2- Then do a full analysis of the current source code (static analysis, > conformance test suites, etc). > > 3- Spread the tasks between bug fixing, feature support, etc. > > 4- Write tickets in a VSC like GitHub (or Savannah, provided everyone stick > to it). > > 5- Set a roadmap and deliverables with expected feature support and bug > fixes, not necessarily deadlines (0.9.27 has been out for a while). > > 6- Set an easy to use cross platform working environnent (unzip and play) for > volunteers to debug and code. > > 7- Get volunteers to take charge of tickets and carry out their holy duty. > > 8- Get their job peer reviewed, merge their commits from separate development > branch into the main one (depending on the workflow used) : > > https://nvie.com/posts/a-successful-git-branching-model/ > > https://medium.com/@sreekanth.thummala/choosing-the-right-git-branching-strategy-a-comparative-analysis-f5e635443423 > > https://dev.to/juniourrau/6-types-of-git-branching-strategy-g54 > > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > > https://docs.gitlab.com/user/project/repository/branches/strategies/ > > 9- Each intermediate (0.9.30, ...) and the final release (1.0.0) should be > performed by grischka once he verified each ticket has been done and tested. > > 10- Reach 1.0.0 in a timely fashion (our lifetime) > > Deal ? > > > > > ----- Mail d'origine ----- > De: Robin Rowe <ro...@trasec.com> > À: tinycc-devel@nongnu.org > Envoyé: Sat, 09 Aug 2025 07:00:39 +0200 (CEST) > Objet: Re: [Tinycc-devel] VERSION Number 1.0 > > >> What is the tcc bug reporting/ticketing system? > > You can get some "tracking" there : > > https://savannah.nongnu.org/projects/tinycc > > So right now we're at 0.9.28rc but a roadmap should be established. > > Thank you, David. That lists 84 bugs. For a roadmap, perhaps the bug > list can be divided to prioritize C99 breakage over C11 support? As a > path toward a more agile release tempo, have C99 be version 1.0 and C11 > to follow? > > Robin > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
