Hello SoX_ng,
thanks for your kind words and your extensive answer(s)! > > [General Guidelines for Development of SoX_ng] > > [preferred code style? mimic the original code style as > > much as possible, even though it is inconsistent?] > If modifying existing code, follow the style of the > original authors, however bizarre that may be, because the > alternatives are either a mix of styles which jars the > eye, or reformatting the whole file to the new style, > which stops any existing patches from applying. If it's > new work, you have the same liberty as the original > authors but yes, something boring and standard is easier > for most people to read. Fine, that is reasonable for me in principle. The problem with the pending patches is that major architectural improvements might be impossible for some time (at least until no further patches are coming in). Take for example the chorus, echo and echos module. Since the code in them is more or less similar, one could put them into a single support module and just do some boilerplate wrappers for the effects in the respective files chorus.c, echo.c and echos.c that all call the common module. I have done this in the SoXPlugins to avoid code duplication. By the way, the same holds for compand and mcompand and for phaser and tremolo. Do we want those kind of changes or postpone them? > > [C standard to be adhered to? C99?] > sox_ng compiles back to -std=c89 and gcc-2-95, which is > necessary for Haiku Okay, I can handle that. > > [guideline for the code documentation? doxygen?] > only libsox is documented with doxygen > see http://martinwguy.net/test/soxygen That looks very promising, well done! > while SoX is documented in man format (and in FEATURES.in). This is fine, but as far as I can tell, the code files for the effects are sparsely commented. My proposal is _not to document everything now_, but just add comments as soon as some file is heavily modified. > libsox[-ng].3 is way out of date, incomplete and in some > cases wrong. > It's on the list. > I assume the libsox doxygen stuff is correct though > browsing its output is most painful with no overview so > the roadmap is probably to take that and refurbish the > libsox manual page, and Jan Stary has done some work in > this direction that will help boost the attempt. Great. > > [guideline: _no executable source code in header files > Yes, I too took a step back when I saw that, though there > are also some strange mechanisms where .h files get > included in several .c files preceded with different > #defines in each context that pick out elements of the > information in the .h file for different purposes. In > other cases it's just an oddness of the author. Yep, but one has to consider that most of the code was designed about 30 years ago and that such trickery might have helped for code inlining and hence efficiency. > > [technique for conditional inlining via xxx.h, xxx.c and > > xxx.c-inc] > > Do we want this technique to be used? > Not if it can be avoided for the reasons you say. Well, I possibly wasn't clear enough: I do not want to promote code in header files under normal circumstances. The technique proposed is about allowing dumber compilers to inline code for production versions. For just a simple example with one function you would do the following: ===== xxx.h ===== void process_sample (sox_sample_t sample); #ifdef Release #define INLINE inline #include "xxx.c-inc" #endif -------------------- ===== xxx.c ===== #include "xxx.h" #ifndef Release #define INLINE #include "xxx.c-inc" #endif -------------------- ========= xxx.c-inc ========= INLINE void process_sample (sox_sample_t sample) { ... do something intelligent ... } -------------------- Depending on the Release preprocessor variable the code is either in the .c-file or in the .h-file. This means that for release builds all the functions are inlined. One problem could be that required old C standard might not support the 'inline' keyword and in that case multiple includes of xxx.h then generate duplicate and erroneous code. > > [put some substructure in the src directory?] > I try to disturb the codebase as little as possible, > partly out of respect for the original authors' vision and > partly because that way the patches and bug fixes that > have accumulated over the last nine years are more likely > to apply cleanly. Okay. > All relevant patches from the 50 distros that package it > have been applied and all the "Patch" tickets from sf.net > have either been applied or entered as a sox_ng issue, but > I have yet to face the work in the 50 or so forks on > github, on sourceforge and elsewhere and the 186 commits > on sox.sf.net since 14.4.2, as well as new work that > various people may be doing. For these practical > considerations, change as little as possible. Understood. > > [several build-techniques used: makefiles, CMake, msvc etc. ] > sox_ng now builds for all the Unices (inc. MacOS X, Haiku > and Minix) and for Windows (thanks to MXE) from > configure.ac and the Makefile.am's and it's been a long > hard slog taking months and stealing time from actually > looking at problems in SoX, so at this point, personally, > I get a kind of revulsion if I try to think about yet more > build systems I don't know and making them work on > everything on the GCC Compile Farm, with its different > versions of all of the libraries, different makes and > shells, different compilers, different places that things > are installed in and presence/absence of features as well > as Windows. Imagine whether I care about maintaining > project files for commercial compilers or having to learn > yet another build system. Sorry, I completely understand that and I fully appreciate your effort in cleaning things up. My idea was to use a unified and single platform like CMake to get rid of the different build tools on different hosts. > Me, I would throw out the msvc dirs and cmake too because > trying to keep four or five build systems working as > changes happen is madness and I cannot verify that any > other than autoconf work, foul disgusting language though > it is, where a single missed double quote or bracket > results in a script generated from a script generated from > the input failing at line 13652 on only one system on the > other side of the planet, probably hundreds of lines after > actual error position in *that* script. > > At present I can say "autoconf builds it correctly on all > supported systems. I have no idea about all those other > things" but have no pressing reason to remove the cmake > support, which still seems to sort of work here on this > system last time I tried it. Its only downside is that > keeping it included suggests it might work and be supported > which is isn't and maybe doesn't. Yep, once you have to support such a multitude of target platforms, some crutches like autoconf are necessary. I have no better idea. > Feel free to maintain a parallel build system but I won't > be considering a switch until it can be shown to work > correctly on Solaris, AIX, Haiku, the BSDs and so on, and > even then I would rather think about other things. I will try to get the CMake files polished in the next weeks. This will then cover MacOS (XCode) and Windows (Visual Studio), at least modern versions of their development environments and we can drop osxbuild and msvcXX. Later we can find out whether other build platforms are also adequately supported by that. Best regards, Prof. Spock -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#37): https://groups.io/g/sox-ng/message/37 Mute This Topic: https://groups.io/mt/110467411/21656 Group Owner: [email protected] Unsubscribe: https://groups.io/g/sox-ng/leave/13602885/21656/313486934/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
