Move ircDDBGateway to use GNU Autoconf #74
Conversation
This continues the work first started with DStarRepeater to convert all of the components of the project to GNU Autoconf on linux.
The wxDateTime header is pulled in automatically when compiled against the GUI libraries. When you're compiling against only the base, you need to pull the wx/datetime.h header by hand.
iostream needs to be included so that it's properly defined. I think this is another example of something that gets pulled in automatically with the GUI applications.
Move ircDDBGateway to use GNU Autoconf
Automake when it adds its missing support files defaults to symlinking them to the installed autoconf versions on your systems. That means that these symlinks will point nowhere for a system that doesn't have autoconf installed. The idiot packager needs to remeber to pass the --copy flag to automake when he sets up the files so that the files will be copied and properly checked into the repository. Missed in dl5di#74.
|
Hi, Before we had this set of *.mk files to configure various pathes (config, data ...). How is this achieved now using the autoconf stuff ? 73 |
I’m removing that in the next couple of days and it’ll default to the more standard /usr/share, /etc, and friends. The paths are changed by using the standard autoconf stuff. You can get help for configure by doing a ./configure —help. It’ll show you the paths changing stuff: Installation directories: By default, For better control, use the options below. Fine tuning of the installation directories: I think I’ll end up changing it so that —prefix defaults to /usr and —sysconfdir defaults to /etc. For the OpenDV apps, CONF_DIR maps to —sysconfdir, DATA_DIR maps to —datadir. You can check out what all these variables get set to by inspecting config.log after running ./configure. There’s probably some fine tuning that needs to go on here too.
Jeremy McDermond (NH6Z) |
|
Hi, I changed the pathes and still it gets compiled with /home/opendv ..... I will do dome more testing |
|
Nvermind I am stupid .... |
|
Hi, I noticed a small issue : 73 |
|
Why has remotecontrold been removed ? |
|
Nothing has intentionally been removed. I think that it just slipped through the cracks because I’m not really sure what to do with it. It’s a misnomer. A program ending in ‘d’ isn’t a “command line equivalent”, it’s a daemon. Daemons are processes that run continuously and do background tasks for the system (see https://en.wikipedia.org/wiki/Daemon_(computing)). The ‘d’ stands for ‘daemon.’ remotecontrold isn’t a daemon. It’s a one-shot command line utility to get the ircDDBGateway daemon to do something. So, it really needs to NOT be remotecontrold, but something else. It can’t be remotecontrol, because this is the GUI utility. The reason it probably came up in my brain is that daemons live in /usr/sbin. Command line utilities live in /usr/bin. It would be awkward to put this in /usr/bin. I think for now, I’ll submit a PR to at least build it and shove it in /usr/bin. But this is clearly wrong, and we need to come up with some other nomenclature on it. Maybe something like dstarctl?
Jeremy McDermond (NH6Z) |
|
Well, it s one of my main tools in various scripting for linking and #!/bin/bash echo " U" >/dstar/tmp/link-c echo $1 if echo "$1" | grep " *unlink" exit 0 else /usr/local/bin/remotecontrold zl2vh__c link never $1 fi You guys pulled my complete host files with gateways into the latest On ssh access, non graphical systems, it is essential. On 20/04/16 02:03, Jeremy McDermond wrote:
|
As mentioned in vk4tux's comments to PR dl5di#74, remotecontrold isn't built. This is probably because it's a misnomer. For now, we'll build it pending some sort of renaming.
|
I'm not saying it's not essential, and like I said, it's something that slipped through the cracks. And I'm also the guy that brought you all the command-line-ish tools that aren't linked with the GUI libraries so that you can have small ssh-only systems. I want the remotecontrold functionality to work because none of my Raspberry Pis have X-windows on them, and I don't want to put it there. Most of this stuff is working towards the goal of having a set of programs that are easier administrated on UNIX-like systems like Linux on the Pi. The complaint isn't the functionality of "remotecontrold," it's the fact that it needs a new name because it's not a daemon. I have the code written for a temporary fix that will at least build remotecontrold for you. As soon as it's passed my CI build server, it'll get a PR. |
As mentioned in vk4tux's comments to PR dl5di#74, remotecontrold isn't built. This is probably because it's a misnomer. For now, we'll build it pending some sort of renaming.
|
maybe ircddbgwctl ? On Tue, Apr 19, 2016 at 9:26 AM, Jeremy McDermond notifications@github.com
John D. Hays PO Box 1223, Edmonds, WA 98020-1223 |
+1 |
|
I like that @johnhays. If we get a consensus, then I'll push another PR with the change. |
|
i dont like it, rctl is much better On 20/04/16 03:01, Jeremy McDermond wrote:
|
My problem is that while rctl is nice, short and succinct, it’s pretty generic and likely to get stepped on by other packages down the road. Right now, I don’t see any files named rctl in packages.ubuntu.com or rpm.pbone.net, but that doesn’t mean there won’t be in the future, and we’re unlikely to be included in any standard distros any time soon. Jeremy McDermond (NH6Z) |
|
Some other, shorter possibilities are: ircddbctl (I'm not sure we need the "gw" part) or ircddbc (This mirrors the ntpd/ntpdc style daemon/control pairs) |
At least there is a binary on FreeBSD... I guess that would also be easily mixed up with something controlling the rc scripts of a Linux system. |
|
The reason I include gw is because that is what is being controlled. It is On Tue, Apr 19, 2016 at 10:13 AM, Florian (DF2ET) notifications@github.com
John D. Hays PO Box 1223, Edmonds, WA 98020-1223 |
|
Joe, ok , yes i modified source code for Fran, and re-compiled on his. That's unusual re using XLX, but ok on that. Did you ask on the ircddbgateway group, so they can look at the code at Jeremy NH6Z, is doing most of it now. A polling parameter change may @ Jeremy,.. is there a wx2.8 master branch still in place to allow regards Adrian On 15/05/16 17:01, Joe wrote:
|
|
It seems like we missed to create a wx2.8 branch... Not good .... |
|
I think it good to keep some compatibility, while those systems exist. I M: 2016-05-15 03:25:28: DExtra link to XRF026 C has failed (poll inactivity) On 15/05/16 22:44, Geoffrey Merck wrote:
|
|
Okay. First, though, this isn't a general purpose thread for issues. If you have an issue, file an issue report in github and let me know about it. That allows me to track and remember things much better. If we know what commit we moved off on to wx2.8, we can certainly make a branch off of there so that someone could cherry-pick commits from master. I, personally, am not going to spend a lot of time worrying about backports. I'm happy to assist other with the backporting bug fixes, but it may not be all that easy as we diverge. I'm doing some restructuring with the daemons that is affecting the threading and such that may not be easy to apply to older code. Yes, @vk4tux, it's good to keep bug fixes and compatibility for a while, but at some point it has to stop. Otherwise you end up spending tons of time supporting ancient software. Microsoft doesn't support XP anymore, much as hams would like them to. Ubuntu doesn't even support their point releases past a year. That being said, I'm not sure I completely understand the issue here. You think there's a bug in the code that's causing the polls to fail? What have you done in the past to remedy this? |
This is the second chunk of moving the entire repository over to GNU Autoconf for building on Linux. It provides configuration for ircDDBGateway. Like DStarRepeater, there is a --without-gui option to build only the command line utilities. Also, even if you enable the GUI pieces, the command line programs are only built with libwxbase.
Please note that commits 15d8842 and c53e103 both change .cpp files to add additional include files. These will need to be tested on Windows before this change is pulled as I do not have my MS development environment up yet. I do not anticipate there are any problems with these, but I never really know without washing it through the compiler.