Allow host to be specified by "name"

[Allan-N]

• updated ami_connect() to allow the host to be specified by DNS "name" (and not just IP address)

• the ami_set_debug_level() function currently requires a session to be specified. This means that there is no way to control the debug level (and any assciated outut) before a session is established. Updated the code to allow one to pass a NULL session to set the default (and pre-session) debug level.

• Allow compilation on macOS

[InterLinked1]

Thanks for the improvements! Just a couple comments:

[InterLinked1]

@Allan-N I updated the CI so it can successfully test PRs, could you just force push your commit? I reran it manually but it looks like it's using the same commit hash, I think if you pushed it again it should work.

Everything looks good so maybe just change the commit title to "Allow host to be specified by hostname, allow logging during session setup" so that it will allow you to push the change and not say nothing has changed.

[InterLinked1]

@Allan-N Any particular reason you changed O3 back to O0? I should've caught that but didn't, and now it's causing various build failures in other projects.

It should've been caught here, so I'm adding additional CI to catch issues like this now, but I'd also like to change that back unless there are other issues you are aware of with that.

[Allan-N]

Any particular reason you changed O3 back to O0? I should've caught that but didn't, and now it's causing various build failures in other projects.

For production code, sure optimize away. But, for development I have found that turning down the optimizations makes debugging so much more useful.

[Allan-N]

Also, kinda surprised that the optimization level of the library presented issues elsewhere.

[InterLinked1]

Also, kinda surprised that the optimization level of the library presented issues elsewhere.

It can cause compilation issues if there are other compiler flags that may not be compatible with the an optimization level of -O0, see: https://github.com/InterLinked1/lbbs/actions/runs/12520332840/job/34925853360

I've reproduced it here: https://github.com/InterLinked1/cami/actions/runs/12520484507/job/34926216949

I'll go ahead and change it back to 3.

[InterLinked1]

But, for development I have found that turning down the optimizations makes debugging so much more useful.

It can, but it's a doubled-edged sword. Many compiler checks are dependent on optimization, so it's not uncommon to enable optimization on a project that didn't use to have it and find it won't build. Disabling optimization can mask those issues.

Luckily, that didn't happen here, the only issue it caused was with gcc itself, there's no issues in the code.

[Allan-N]

Been looking at Options That Control Optimization

Maybe use -Og :-)

Or go back to -O3 ... and I'll change it to -O0 or -Og when I need to use gdb/lldb

[InterLinked1]

Been looking at Options That Control Optimization

Maybe use -Og :-)

Or go back to -O3 ... and I'll change it to -O0 or -Og when I need to use gdb/lldb

The repo is set up so that it can be used directly in other programs when built, so that's why it's using O3. It was initially O0 for a long time but I changed it to 3 when I decided the library was stable and relatively bug-free.

I agree -Og is superior for debugging and makes sense, it's more so that local dev changes shouldn't be pushed upstream - most users aren't developers and won't be debugging it, it will just slow their program down unnecessarily :)

But I'm actually glad this happened as the additional CI should do a better job catching related issues in the future. Debian tends to lag a bit behind on gcc versions.