> IMO, a config file is a lot more readable than a bunch of bloated compiler
> command lines. It would be even more so if it included comments. :-)
The -v output is a lot more readable since I removed the config file stuff
from the command line.
--
These are my opinions. I hate spam.
__
Ian Bruene via devel :
>
> First issue (blocker)
I see you solved this one already, good work.
> Second issue (non-blocker, but ugly)
>
> In order to run unit tests on python code the "pytest" waf module is
> required. Attempting to load it normally failed, leading me to believe that
> it was n
Fred Wright via devel :
> I recall something at Google where there was a bash script with an
> endian-sensitive argument. Only of academic interest at the time.
That is hilarious. And sad. And hilarious again.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by
On Wed, 29 Nov 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
> >
> > On Sat, 25 Nov 2017, Hal Murray via devel wrote:
> >
> > > It seems like a good idea for somebody to actually test our code on a
> > > big-endian system.
> >
> > I've run it on my PowerBook (OSX 10.5), though I didn't at
On Sat, 25 Nov 2017, Eric S. Raymond via devel wrote:
> Hal Murray :
> > devel@ntpsec.org said:
> > > waf doesn't know that config.h exists; this is its way to pass
> > > configuration
> > > switches. The fact that we generate a config.h is really legacy behavior
> > > from autoconf and could b
Fred Wright via devel :
>
> On Sat, 25 Nov 2017, Hal Murray via devel wrote:
>
> > It seems like a good idea for somebody to actually test our code on a
> > big-endian system.
>
> I've run it on my PowerBook (OSX 10.5), though I didn't attempt any
> detailed analysis of the behavior. The clock
On Sat, 25 Nov 2017, Hal Murray via devel wrote:
> It seems like a good idea for somebody to actually test our code on a
> big-endian system.
I've run it on my PowerBook (OSX 10.5), though I didn't attempt any
detailed analysis of the behavior. The clock offset had more wander than
I'd like, bu
On Wed, 29 Nov 2017, Ian Bruene via devel wrote:
>
> On 11/29/2017 04:17 PM, Hal Murray via devel wrote:
> > That link lets you test python code using the new libraries.
> >
> > In a previous version of that code, the link was in ntpclients and you could
> > run things by cd-ing there. Now the li
The first issue has been solved, I stopped blanking out on the relevant
build code for creating symlinks and figured out what did what.
The second issue remains.
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Chooses, a Slave Obeys."/ -- Andrew Ryan
/"Utopia c
On 11/29/2017 04:17 PM, Hal Murray via devel wrote:
That link lets you test python code using the new libraries.
In a previous version of that code, the link was in ntpclients and you could
run things by cd-ing there. Now the link is in $build/main/ntpclients so you
have to cd there. Are you
> The cause of this issue is that the python libraries are stored in pylib/
> but installed (and referenced in the code) as ntp/. Previously this caused
> import problems that were solved when someone added code to create a
> symlink from ntp/ to pylib/ at the end of the build process.
That
First issue (blocker)
I have succeeded in getting the unit testing scripts for python code to
run as part of the build on my machine, however when uploaded to GitLab
the pipelines fail with an import error in the test scripts. The test
modules cannot import the library modules they are meant
12 matches
Mail list logo
