X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Tue, 20 Sep 2016 13:12:27 +0200 (CEST) From: Roland Lutz To: "dmn (graahnul DOT grom AT gmail DOT com) [via geda-user AT delorie DOT com]" Subject: Re: [geda-user] Default gnetlist frontend changed In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Hi Dmitry, thank you for sumbitting this patch! :) If I understand it correctly, these are actually four different problems: On Tue, 20 Sep 2016, graahnul.grom wrote: > - hard-coded python binary path > - hard-coded python include path > - hard-coded guile include path In which paths are Python and Guile installed on your system, respectively? What's the preferred way to determine this on FreeBSD? Is there a reason for you to choose `python-config' and `guile-config' over `pkg-config'? > - non-portable C++ code in key_iterator.h It's in C++98, so how can it not be portable? Are there additional language restrictions present in FreeBSD? I tested the code with both g++ and clang++ and the `-std=c++98' and `-pedantic' options, and the only warnings I got were about empty macro arguments and commas at the end of an enumeration. > Furthermore, xorn can be built using GNU sed (gsed) only. > So, potentially there are more portability problems. The intention is that Xorn shouldn't depend on GNU sed; if it does, that's a bug. What problems did you encounter with non-GNU sed? > xorn.guile.lookup(guile_proc)('/proc/self/fd/%d' % f.fileno()) > > Unfortunately, there is no /proc/self/ directory on my system - FreeBSD. What's the preferred way on FreeBSD to address a file descriptor as a file? Is there such a way at all? The other obvious way to implement this would be to redirect the standard output, and let the backend output there. I tried to avoid this as it may cause some messages printed to stdout to be included in the output, but maybe it's the better option considering portability. On Tue, 20 Sep 2016, M. J. Everitt (m DOT j DOT everitt AT iee DOT org) [via geda-user AT delorie DOT com] wrote: > Ewwww, what on earth hard-coded horror is this?! How would you solve this? Roland