| Hi Benjamin,
Of course. But what is wrong with the websites? Do they not precisely what you ask for?
In my view anything else is of course only something that matter for the developer and I understood this to be the topic of the discussion. And I fully concur that also as a developer I must put myself in the shoes of a user. Anything else is of little use generally and not particularly professional.
So I fear you have rather misunderstood me or perhaps I did not well understand what the purpose of the discussion is?
Andreas
ETH Zurich
Prof. em. Dr. Andreas Fischlin Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 24 Universitaetstrasse 16 8092 Zurich SWITZERLAND
+41 44 633-6090 phone +41 79 595-4050 mobile
Make it as simple as possible, but distrust it! ________________________________________________________________________
On 24 Mar 2024, at 08:50, Benjamin Kowarsch <trijezdci@gmail.com> wrote:
I am sorry but as a user of a library, I want my convenience to rank above the developer's preferences and convenience. As a user, I want to see the interfaces without any clutter. Thus I want those interfaces in one place without anything else being visible to me. And if I need to dig any deeper into it, looking at how it is implemented, then I want to see the implementations without any clutter as well, thus again in one place without anything else being visible. I do not care whether the developer of the library finds this representation practical or palatable to themselves. It is most practical for the library user. And thus, I simply demand it that way. Besides, even as a developer, I am also a user of the library, and using the library is the ultimate reason why I develop it. And thus, my requirements as a user have priority over my considerations as a developer.
regards benjamin Hi all,
We used folders to separate the various libraries. E.g. ‘DMLibDev' for the "Dialog Machine" (DM https://sysecol.ethz.ch/ramses/ramses-software-layers/dialog-machine-dm.html). The latter was subdivided into two layers, i.e. subfolder ‘Base' for the modules used by the DM itself and that contained platform dependent code) and the subfolder ‘High' for the higher layer, i.e. all modules that were available and visible to the user of the DM.
Within any such folders we always had further subfolders such as ‘Tests' and ‘DevAux’. ‘Tests’ contains all test program modules with any required input data and expected test results. ‘DevAux' contains all make lists/scripts and other project specific informations of interest to the developer.
Andreas
ETH Zurich
Prof. em. Dr. Andreas Fischlin Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 24 Universitaetstrasse 16 8092 Zurich SWITZERLAND
+41 44 633-6090 phone +41 79 595-4050 mobile
Make it as simple as possible, but distrust it! ________________________________________________________________________
Actually, I use "imp" for the subdirs that contain the .mod files, not "mod".
On Sat, 23 Mar 2024 at 07:40, Gaius Mulley wrote:
john o goyo writes:
> [~/opt/Alice]=> gcc-git -c -fiso -I. CardBitOps.mod
> <built-in>: error: the file containing the definition module cannot be found
>
> Gaius, any insight here?
yes gm2 is trying to create a definition module symbol and cannot find
the CardBitOps.def file, and uses the builtin location (previously it
would give a misleading error message location in the implementation
module source file). Perhaps the error message could be improved
though?
I also separate .def and .mod files in my projects.
However, I put the interfaces in the top levels of each source tree directory and the implementations in their respective imp subdirectories
/src /... any library subdirs ... /mod foo.mod bar.mod foo.def bar.def
The reason why I believe that the interfaces belong in to the top level is that source code should always be presented for the ease of use and convenience of the reader, not for the convenience of the author. For the user/reader, the most important part of a library are the interfaces. They may never even look at the implementations, but they will need the interfaces.
Therefore, if the two are separated to reduce clutter which also makes the library easier to use for readers, then the interfaces should go in to the top level, and the implementations into a subdirectory.
Perhaps, GM2 could accommodate this kind of source tree structure with a simple compiler switch.
regards benjamin
|
smime.p7s