NanoVNA-QT: cc1plus: error: unrecognized command line option "-std=c++0x"

[ryandesign (Ryan Carsten Schmidt)]

​NanoVNA-QT does not build:

cc1plus: error: unrecognized command line option "-std=c++0x"

This is because although the portfile specifies compiler.cxx_standard 2011 it is not UsingTheRightCompiler. It has this block that does the autotools part of the build manually:

post-configure {
    system -W ${worksrcpath} "CPATH=\"${prefix}/include\" LDFLAGS=\"-L${prefix}/lib\" CFLAGS=\"-I${prefix}/include\" ./configure --prefix=${prefix}"
    system -W ${worksrcpath} "CPATH=\"${prefix}/include\" LDFLAGS=\"-L${prefix}/lib\" CFLAGS=\"-I${prefix}/include\" make -f Makefile"
}

This does not preserve all of the variables that MacPorts would set if it were running these commands normally. Specifically, note that CC, CXX, CXXFLAGS are not being set.

It is unfortunate that this software apparently has a qmake part of the build and a separate autotools part of the build. MacPorts isn't really designed to accommodate running two different things in a phase, but it can be coerced into doing so... (for example, you can override the configure phase and in that block, invoke portconfigure::configure_main to run the normal configure phase, then modify configure env, args, etc. as desired, then invoke portconfigure::configure_main again. portconfigure::build_main is also available. These are internal MacPorts functions not intended to be used from Portfiles (indicated by the :: in the name) and this usage may break in a future version of MacPorts. But I use it in the php 1.1 portgroup for example and there are a handful of ports that use it: astyle, nlohman-json, freeimage, reduce.) Or you might be able to get away with just modifying configure.cmd or build.cmd to do two things.

[ryandesign (Ryan Carsten Schmidt)]

Or, since a comment in the Portfile above the post-configure block reads # build libxavna, is it perhaps appropriate to make libxavna a subport upon which this NanoVNA-QT can then depend? Then the main port can build with qmake and the subport can build with autotools and everything is easy.

[ra1nb0w]

As always, thank you Ryan for your help ;-)

I did many tests before reach this "not so good" solution. I though also to use subport, this should be the best way, but I didn't find a way to remove Portgroup qmake5 from the subport without rewriting the cmds and doing messy code. qmake should find libxavna also from ${prefix}/lib therefore the build should work. Have you some suggestion?

Generally, I don't like to use private functions.

[ryandesign (Ryan Carsten Schmidt)]

Agreed about not wanting to use private functions if possible.

You can't remove a portgroup once it's been added, so only add it when you need it. For example, if you only need it in one subport, then only add it in that subport's block. Or if you only need it in the main port, do something like:

if {${subport} eq ${name}} {
    PortGroup ...
}

I spent some time trying to fix this today but there are so many things wrong with the build system that it's becoming very frustrating.

It also seems like this is a continuation of work that began in a different repo: ​https://github.com/xaxaxa-dev/vna. Do you know anything about the relationship between these two repos? Not sure why but NanoVNA-QT appears not to have forked that repo but rather to have imported all the code into a fresh repo, thus losing the commit history. Should we be making a libxavna port from xaxaxa-dev/vna instead? Would that be compatible with NanoVNA-QT?

[ryandesign (Ryan Carsten Schmidt)]

I see you committed [c4f9548714e53f9e37840503646a152b348741db/macports-ports]. Remember to include the ticket URL in the commit message to link things up.

It's actually libxavna that requires eigen3 and fftw-3. Use trace mode to discover these problems before committing.

[ra1nb0w]

ooo true. I used extensively on Gnuradio 3.8 ports. thank you

I updated the port; check it out.

about libxavna: I know that was a copy but there are some changes to accomodate DFU firmware upgrade and changes about the chunck size during sweep (essentialy the function that generate the signal N times and read back the magnitude and phase). Therefore I don't touch it. If in the future we need to accomodate both we can change the name or ask to the developers.

[ra1nb0w]

Replying to ryandesign:

I see you committed [c4f9548714e53f9e37840503646a152b348741db/macports-ports]. Remember to include the ticket URL in the commit message to link things up.

Ops. right. I need to rembember this point!

It's actually libxavna that requires eigen3 and fftw-3. Use trace mode to discover these problems before committing.

I am usualy use otool to checkout which dependencies they need (trace is slow - already know issue). Anyway, from now I always try use trace.

[Davide Gerhard <ra1nb0w@…>]

In 8585708bc76e06ce98180984028f538f737756b5/macports-ports (master):

libxavna: fix dependencies

with commit c4f9548714e53f9e37840503646a152b348741db
Closes: #60323