Skip to content

Compatibility Changes (+ CMake QoL Changes, MSVC Build Fix)#2

Open
lenakryger wants to merge 4 commits into
SuperKogito:mainfrom
lenakryger:main
Open

Compatibility Changes (+ CMake QoL Changes, MSVC Build Fix)#2
lenakryger wants to merge 4 commits into
SuperKogito:mainfrom
lenakryger:main

Conversation

@lenakryger

Copy link
Copy Markdown

Automatically fetch dependencies so that fastft builds "out of the box". Tested with MSVC 2019.

…at the library works "out of the box". ToDo: fix failing tests with MSVC2019
…nary output dir as a post-build event). Tested with MSVC2019. ToDo: verify with MinGW/GCC
… with filename changes, this is to avoid conflicts with other DSP libraries as C has no namespaces or polymorphism.
@lenakryger

Copy link
Copy Markdown
Author

I added some more changes to prevent potential issues

  1. Prefixes and types for interface types
    • C libraries have no namespaces so it's good practice to prefix everything that you declare.
    • In a complex enough DSP system there could be multiple DSP libraries, all in the global namespace, all with their custom types
      • Imagine if two libraries typedefed "Signal", you'd suddenly have conflicts upon conflicts when including headers from two libraries
      • The same goes for functions, C has no polymorphism
        • Once you declare a symbol, that's it, the name is "taken", any other declaration even if it's with different types is an error
          • Example: "write_to_csv", "write_wav_file" - both of which were in "signal.h"
  2. Prefixes for header files and header guards
    • Again, imagine if your lib user uses 3 different libraries in one project and all of them try to include "signal.h"
      • Trying to fix it in the build system (by modifying the include directory order/structure) would be a major pain
    • Two solutions are possible:
      1. Rename "signal.h" to "fastft_signal.h" (and all others similarly)
      2. Make sure that you always include headers with their top directory e.g. "fastft/signal.h", and never add "fastft/" to project include dirs directly
    • The second solution is usually used for larger libraries, so I just renamed all headers by adding a prefix

Additionally, while changing the interface, I also took the liberty of:

  • Changing file names to better match the interface (e.g. "pad.h" to "fastft_padding.h", as all the interface functions declared there contain the word "padding")
  • Rearranging the word order so that more function names match the pattern fastft_{header/struct-name}_{function-name}
    • e.g. fastft_padding_apply and fastft_padding_init in 'fastft_padding.h' instead of apply_padding and init_padding in 'pad.h'

@lenakryger lenakryger changed the title CMake Quality of Life changes + MSVC build fix Compatibility Changes (+ CMake QoL Changes, MSVC Build Fix) Aug 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant