On 06/01/25 21:17, Prof. Spock via groups.io wrote:
I am the author of the SoXPlugins that mirror some of the SoX
functionality in audio workstations
Your work is appreciated too!
* What is the preferred code style? I fully understand that one
tries to mimic the original code style as much as possible, but
since the have been several contributors over the time, there is
no real consistency.
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.
* What is the C standard to be adhered to? Is is C99 or something
later?
sox_ng compiles back to -std=c89 and gcc-2-95, which is necessary for Haiku
* Is there some guideline for the code documentation? One could use
something like doxygen to produce readable internal documentation
from the code, but, of course, has to adapt the code documentation
accordingly.
My proposal: doxygen
only libsox is documented with doxygen
see http://martinwguy.net/test/soxygen
while SoX is documented in man format (and in FEATURES.in).
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.
* I would prefer _not to have_ executable source code in header
files. This might impede efficiency, because optimization might
not work, but there is a remedy for that: put the executable
source code in some "xxx.c-inc" file and - depending on the build
configuration - either include it into the xxx.h file or include
it into the xxx.c file.
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.
Do we want this technique to be used?
Not if it can be avoided for the reasons you say.
* Do we want to put some substructure in the src directory (like
e.g. effects, formats, basetypes etc.)? This makes includes a bit
more tedious, but in my opinion this is helpful.
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.
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.
* There are several build-techniques used: makefiles, CMake, msvc
etc. First of all, I would prefer to have those in some build or
buildSetup directory on top level.
CMake has the big advantage that it generates the build files:
hence one can throw away all the MS vcxproj and sln files and also
the makefiles.
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.
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.
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.
More of this in a tick for your other mail...
M
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#35): https://groups.io/g/sox-ng/message/35
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]]
-=-=-=-=-=-=-=-=-=-=-=-
