Improvement

[ccodere]

Greetings,
After 4 years of silence, I am back trying to compile ACK with CMake, and its going fairly better than last time...

I am currently at the platform building phase and by evaluating the libc source code and the different platform rules, i see a lot of things which causes some
confusion and would like to discuss:

1. Some functions are not ISO C90, or are either based on XSI or C99:
   1. ctype: isblank, isascii, toascii
   2. string: strdup, memccpy
   3. stdio: snprintf. vfscanf, vsnprintf, popen, getw, putw
   4. stdlib: putenv, setenv, mktemp
   5. Others: getopt, termcap, isatty, getpass, sleep
2. Some functions which are in core are actually not really portable
3. The directory structure of the files in libc is not by module
   (header file)

Hence i propose the following in my upcoming patch in my fork:

1. Create a cmake optin to select to be strict ISO C90 or support some
   of the above extensions
2. Move some files under libcc.ansi/core into their respective module
   directory (misc should no longer exist), and have the same mirror
   under libcc.ansi/sys

What do you think? The idea is to also mirror this libc directory structure for each platform that wish to override some of the C functions.... For example for stdlib:

• libcc.ansi/core/stdlib
• libcc.ansi/sys/stdlib
• plat/linux/libc/stdlib
• plat/linux68k/libc/stdlib

The two last directories are optional and only present for example if you wish to override some functions of stdlib.c... Hence the search for the source files would be in reverse order of this list.

Any comments?

Carl

[davidgiven]

Ooh, cmake. You're brave!

Regarding the libc file structure: you're right, it's not by header file, which is intentional. The C headers combine portable functions and non-portable functions in the same file. Consider that stdio contains rename, which is a system call supplied by the plat, and fopen, which is supplied by the libc. So, they're divided up correspondingly, more or less by function.

Regarding ISO C90: no, it's not --- it's more like Posix (although not a very new Posix, and with rather hit-and-miss coverage). What's the value of ISO C90? It's very restrictive... The C99isms were added because it was little work and allows clearer code.

Regarding the cmake optin: the way the ACK is supposed to work is that it builds all the combinations of all the platforms (this is one of the things which cmake isn't good at). So if you wanted a strict C90 variant, it'd be more fitting to either build each libc twice and allow the user to select which one to use as an ack command line flag, or else (which is probably preferable, and much less work) to use #define feature macros to let to the user configure the C library. That would first require someone to look at the headers and figure out which standard they're roughly conforming to, which hasn't been done yet.

(I'm not averse to rearranging the libc if it'll help things, but there are actually reasons why it's arranged the way it is.)

[ccodere]

Greetings,
Regarding the libc, i understand a slightly more the philosophy, but i saw that all implementations should probably implement a subset of POSIX to work, in libsys, is that correct? The issue is that system.c relies on fork and exec of libsys which is impossible to implement on some platforms, hence how to manage this in that case? As i proposed system.c would be overriden by those platforms, but today how is it managed?

Iits not necessary to have strict C90, i just would like that basic functionality has a similar base per platform when possible and that adding a new platform should not be very difficult. For the standards and what they conform to, i have done this tedious exercise, in a cmake include file (not very clean), its attached in this file.

proto.cmake.txt

I currently commented out extended files of libc, but following your comment, will probably readd them..

You are right, to ensure a pure libc usage it would be best to rebuild differently and this libc be selectable at compile time, so probably not worth the effort in that case...(for me at least)..

The strategy i have for CMake usage is the following ideas:
2 build phases with CMake:

• First build phases builds everything for the host (this is 95% done, currently working on docs, and emulator compilation).
• Second build phase uses a CMake toolchain file to build the platform targets and run the tests
  This could be done in a shell/batch file or master make at project root that would call the 2 phases of Cmake.... Still looking into the details of this...

Carl

[davidgiven]

Right now I'm not sure if any plats actually do override the libc. The way to do it would be to put the override functions into another library and make sure it appears before the libc in the link order, so that by the time the linker sees the libc, those functions are resolved. I'd need to check to make sure it works, though.

The intention is that a plat need only implement a very small number of functions for the base system calls, and then the libc would do the rest. Look at plat/pc86/libsys. The only functions there which actually do anything are brk/sbrk, read/rawread, and write/rawwrite. I don't really know how that could be simplified!

Regarding building with cmake... this sounds like it would require many passes through cmake; one for the host tools, and then one for each plat (and plat variant). That seems to me to be incredibly cumbersome. I know the current build scripts are bad (I have a much better replacement ready to go), but I would think this would be worse.

[ccodere]

Greetings,
Thanks for the insights on how it would work today to override a function, of course its not so clean but it may work, i still prefer the proposal i have as it makes things clearer i think.

In regards to pc86 i will definitely take a look, i see also that you can disable features of libc with ACK_CONFIG defines from my understanding.

For CMake, only 2 passes would be required, as there is a way to set the machine for each different plat and do it in one shot if you use one generic toolchain file representing ACK, i know that QNX build system can target different machines with one single toolchain file, but i am not yet at this step though, probably it would be flags set per platf directory.