Hello Eric, czw., 4 mar 2021 o 09:25 Eric Bollengier <e...@baculasystems.com> napisał(a):
> On Debian at least, users have the choice between two readline > implementations, libedit and libreadline. They are supposed to be > compatible (this is mostly a license issue with libreadline if I > remember correctly). > In my very humble opinion Bacula Community does not support editline but supports readline. This is the same exact situation as we have with mysql and mariadb. Both tools are compatible and could replace each other but to some extent. Differences are subtle but prohibits a straightforward installation and updates (#basedonexpirience). and the Debian is using readline only for Bacula: # /usr/sbin/bconsole -? Copyright (C) 2000-2016 Kern Sibbald. Version: 7.4.4 (20 September 2016) x86_64-pc-linux-gnu debian 9.13 (...) # ldd /usr/sbin/bconsole linux-vdso.so.1 (0x00007ffd621a4000) libreadline.so.7 => /lib/x86_64-linux-gnu/libreadline.so.7 (0x00007f0e30c62000) libhistory.so.7 => /lib/x86_64-linux-gnu/libhistory.so.7 (0x00007f0e30a58000) (...) > The libedit readline.h is available under: > /usr/include/editline/readline.h > > We might change the "" to <> in the header or even do some more > advanced detection, but using only <readline/readline.h> will force > users to patch the source to compile with libedit. > > So, if we want to support Bacula with editline as the replacement for readline then we should extend our detection code and add a proper compilation option. This is my humble opinion. > > I'm pretty sure that we use it incorrectly as the whole code goes like > this: > > > > #ifdef HAVE_READLINE > > #define READLINE_LIBRARY 1 > > #include "readline.h" > > #include "history.h" > > ... > > > > But our code is not a readline library code, so why do we define this > > macro: READLINE_LIBRARY at all? > > What I understand from the readline code is that this macro is used to > > distinguish between "internal" and "public" usages. > > We should use a public interface of readline, right? So if public then > > readline developers designed it as: <readline/*.h> > > > > What do you think? > > The READLINE_LIBRARY flag is a readline option to be able to locate the > readline headers in an other directory than readline/, Which is strange for me as no readline version I tested supports this kind of installation. > for me this is a > compatibility trick that might not be necessary anymore, but that > doesn't cost anything, and might be used by some users. > In my humble opinion no user is using this trick with Bacula as the proper readline installation always uses $includedir/readline/ directory. So no proper readline headers exist outside this $includedir/readline/. > I wrote this code in 15 years ago, and I'm pretty sure it was needed to > compile properly, else it would not be here. After, I do not remember > all details. > Which is very strange to me and I do not understand it as even the readline 2.0 from 1994 in the examples and technical documentation points to #include <readline/readline.h> as the proper way to use this library. I assume there is something I miss here but everything I check convinces me that the current code should be fixed. > If you want to rewrite this part, I think it's ok, but you need to > support a dynamic location of the readline.h file (at least 3 places) as > it is today. > If you are sure that the editline library is a drop-in replacement to readline then it is trivial to add this library detection and start to support it officially. best regards -- Radosław Korzeniewski rados...@korzeniewski.net
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
