Skip to content

Contrib#17

Closed
asappia wants to merge 4 commits into
Raizo62:betafrom
asappia:beta
Closed

Contrib#17
asappia wants to merge 4 commits into
Raizo62:betafrom
asappia:beta

Conversation

@asappia
Copy link
Copy Markdown
Contributor

@asappia asappia commented Feb 17, 2025

  • Change MTU

  • Fix gcc Warning with gcc14

  • Add shell.nix to ease local development with all needed libraries and tool in scope

  • Use CMake for building to ensure cross compilation / compilation in buildroot/fakeroot

  • Removed Makefile/Makefile.in/ Makefile depenencies

Signed-off-by: Alessandro Sappia <a.sappia@gmail.com>
Signed-off-by: Alessandro Sappia <a.sappia@gmail.com>
Shell.nix includes all libraries needed for local development

Signed-off-by: Alessandro Sappia <a.sappia@gmail.com>
This ensure:
- cross compilation
- buildroot/fakeroot builds
in automated build environments
@Raizo62
Copy link
Copy Markdown
Owner

Raizo62 commented Feb 17, 2025

Hi

I have merged the 2 first commit

  • Set MTu to 2352 as per ieee80211.h linux header
  • Fix gcc Warning with gcc14

Thanks :-)

Next time, consider using a new branch for each pull request topic. Otherwise, we are forced to accept or reject everything.

I think that shell.nix must be in tools folder : It is specific to NixOS.

Sorry, I'm still not convinced by CMake. I find it too heavy.
Besides, we must also add "make" on the README if we are on a system that installs the minimum of packages
Why does the Makefile variable redefinition not suit you? (make CXX="clang")

I think that explanations about shellcheck are not necessary for CMake ;-) So new branch/new commit.
Also, I think these explanations are more appropriate in a wiki page. This complicates the explanations for vwifi.

@asappia-tii
Copy link
Copy Markdown

I get the hesitation around CMake, but relying on Makefile variable overrides (e.g., make CXX="clang") doesn’t scale well for packaging, cross-compilation, or structured build systems like Yocto, Buildroot, NixOS, and Linux distributions.

Cross-compilation & packaging need a reliable way to specify toolchains and dependencies.
CMake natively supports toolchain files, while Make requires manual tweaks.
NixOS needs declarative dependency resolution, which structured build systems handle better.
Makefiles require platform-specific fixes, whereas CMake abstracts this away.

At the end of the day, CMakeLists.txt is just one file (replacing Makefile, Makefile.in, and Makefile.dependency.sh), but scales better, works cross-platform, and integrates with modern toolchains.

If dependencies are a concern, Meson is a lighter alternative. But Make alone will eventually be a bottleneck.

For example, in NixOS packaging, we have to patch the Makefile to make it work—CMake would avoid that.

Let me know

@Raizo62
Copy link
Copy Markdown
Owner

Raizo62 commented Feb 23, 2025

I've been thinking about it since your post. My heart swings between the 2 and I can't decide.

I find CMake too heavy and less powerful:

  • I don't find the optimized dependency management obtained with the “Makefile.dependency.sh” script. Very useful for keeping building times down when modifying complex code.
  • I don't like your git version number management. When troubleshooting issues, simply adding “-dev” is not enough. I prefer the version number to include the small number of the last commit. (Or maybe I missed something.)

But, on the other hand, CMake simplifies cross-platform, and is integrated with modern toolchains....

Is it possible for CMakeLists.txt to generate a Makefile capable of “make gitversion” ?

If you don't mind, could you create a new “cmake” branch that contains only the cmake modification (no cppsheck, no NixOS, ....) ?

@asappia-tii
Copy link
Copy Markdown

asappia-tii commented Mar 25, 2025 via email

@Raizo62
Copy link
Copy Markdown
Owner

Raizo62 commented Mar 25, 2025

Hi

What is the Unit of Measure for the X, Y, Z coordinates ? Meters ?

Yes.

What is the model signal strength

packet loss based on distance ?

Yes, with probability ( bool CWifi::PacketIsLost(TPower signalLevel) )

I decrease the signal strength with this attenuation :
TPower signalLevel=BoundedPower(power-Attenuation(coo.DistanceWith((*InfoWifis)[i]),frequency));

Attenuation() uses this formula ConstanteC+20*log10(frequency/1000)+20*log10(distance/1000) that I had to find on the Internet.

@asappia
Copy link
Copy Markdown
Contributor Author

asappia commented Mar 25, 2025 via email

@Raizo62
Copy link
Copy Markdown
Owner

Raizo62 commented Mar 25, 2025

[...] Meters ?
So those are mettere ? Or what?

Yes : meters

@Raizo62
Copy link
Copy Markdown
Owner

Raizo62 commented Jul 27, 2025

  • Change MTU : done
  • Fix gcc Warning with gcc14 : done
  • Use CMake for building to ensure cross compilation / compilation in buildroot/fakeroot : done
  • Add shell.nix to ease local development with all needed libraries and tools in scope : Nix support #19

@Raizo62 Raizo62 closed this Jul 27, 2025
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.

3 participants