-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design of FoOtS #1
Comments
Dear Paul, Firstly I would like to thank you for this great contribution, it is very welcome! I am going to try to replay to your questions, but I doubt I will success... Some preliminaries:
Now I am trying to replay to your questions:
I do not know this project. I will study it soon. At a first view it seems very good, thus maybe FoOts will never born... I do not like to reinvent the wheel :-) Thank you very much to focus us to it!
My effort will be devoted to only GNU Linux, but I hope that other members will test FoOts on other architectures.
I am confident to support both. If FoOts will born it will be based on a robust/diffused/mature C back-end, meaning that the underling C library should be very portable. Fortran has a lot of wonderful compilers able to port codes on a wide OS jungle (32bits, 64bits, RISC, CISC, ARM...) so when (if) we chose the C library we should take into account its portability.
The FoOts API is far from being defined... I have no idea of which approach we would like to take. Surely, if the APIs you highlighted (I know something about boost) are good for us we will be happy to adopt them. However, Fortran poor people often think differently from C/C++ rich ones, so I will not surprised nor irritated if we finally design a different (more Fortranish) API. Please, continue to support us with such a great contribution, it is very appreciated! Stefano P.S. I am going to study modFileSys, maybe FoOts will die before it will born. |
I have quickly read the thread you mentioned. Is this portability issue strictly related to the libc, or is it commonly diffused to other C libraries (boost and others)? |
Dear Mr. Zaghi,
I discovered with great interest your project "FoOtS" on GitHub :
https://github.com/Fortran-FOSS-Programmers/FoOtS
Thank you for your work on this project and on your other Open Source Projects.
I am not currently able to contribute to your project, but please find below some remarks whose intention is to be helpful.
How does your project compare with the modFileSys project ?
https://bitbucket.org/dftbplus/modfilesys
https://aradi.bitbucket.org/modfilesys/
Will your project be usable under Windows ?
For a sample, in Fortran, see for example :
https://groups.google.com/forum/#!msg/comp.lang.fortran/bU02_Q3ZB7s/Xy8F0U5mvckJ
Will your project will portable on 32-bits and 64-bits operating systems ?
Under POSIX, the members of the "dirent" structure seemingly differ depending on whether the system is 32 or 64 bits. See for example :
https://gcc.gnu.org/ml/fortran/2007-08/msg00167.html
https://gcc.gnu.org/ml/fortran/2007-08/msg00175.html
On Windows, STDCALL calling convention should be required 32-bits version.
Most importantly : instead of defining your own Fortran interface (e.g. the names of procedures), did you consider the possibility to mold your interface on one of the existing libraries ?
My preference would go to the Boost Filesystem Library project :
http://www.boost.org/doc/libs/1_33_1/libs/filesystem/doc/design.htm
http://www.boost.org/doc/libs/1_33_1/libs/filesystem/doc/index.htm
http://www.boost.org/doc/libs/1_33_1/libs/filesystem/doc/portability_guide.htm
Another possibility could be the Fortran POSIX interface :
http://standards.ieee.org/findstds/standard/1003.9-1992.html
IEEE 1003.9-1992 was withdrawn, but some compilers (for example ifort) include access to POSIX functions :
https://software.intel.com/en-us/node/580295
See also the NAG compiler :
http://www.nag.co.uk/nagware/np/r60_doc/f90_unix_dir.html
http://www.nag.co.uk/nagware/np/r60_doc/f90_unix_dirent.html
Another interface (POSIX and Windows) is defined by the functions group "Files Utilities" from the glib library :
https://developer.gnome.org/glib/stable/glib-File-Utilities.html
These functions handle file names with any Unicode characters in them on Windows without having to use ifdefs and the wide character API in the application code.
Yours faithfully,
Paul Martin
The text was updated successfully, but these errors were encountered: