Error on "make test" after npm install telehash-c (OSX)

[cfvaughnii]

ld: can't open output file for writing: bin/test_lib_base32, errno=2 for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: * [bin/test_lib_base32] Error 1 make: * [test] Error 2

The reason: There is a telehash-c/test/bin directory in the telehash-c repository. However, there is no telehash-c/test/bin directory after an npm install telehash-c on OSX. Does the .gitignore file in test/bin cause the directory to be skipped?

[jbdatko]

This is more of rant than a direct answer to your question.

Perhaps I'm old fashioned, but for C code, I think autotools is the way-to-go to build the tarball as a released package vs. pulling from Github. (Github supports features so you can upload the tarball as a feature, which is just on S3, and have automated things pull it down).

I think @quartzjer would blow a gasket if I turned telehash-c into an autotools project but, one could specify in autoconf/automake what files were going into the distribution rather then relying on the version control's system of ignoring files.

/rant

[quartzjer]

I wouldn't blow a gasket, but I have a lot of autotools scar tissue that I'm not keen on dealing with :)

Ages ago my goal was to have telehash-c be two projects, a lower level pure C one similar to sqlite.c that can be embedded into anything, and a higher level project w/ all the unixy and friendly/wrapper stuff (and yes, autotools), but it isn't so clear if that's the best way to organize it still... thoughts welcome!

[jbdatko]

The two approaches makes sense. But like sqlite, they offer both the source code that you can download & they are in the OS vendors packing system. So, I don't think they are incompatible.

I think you'd want to structure the project as autotools overall. Then add a target that makes the one-c-file like sqlite does. But autotools makes it much easier to package into debs and rpms. Ultimately, a user should be able to apt-get install telehash-c.

The bastard child is arduino however. That could also been in the autotools configure. So, you download the tarball and you make arduino which should probably produce an arduino library.

The releasable thing should be a tarball however, not the github project. I can fork the repo and try to put an autotools wrapper to let you see how the unixy would work...

[quartzjer]

fyi @jbdatko, my long term goals for telehash-c as a codebase have evolved to it being primarily for embedded usage, and not aimed to easily accommodate traditional desktop/server apps or as a shared lib. I would much rather energy be put into dedicated implementations for them using newer (safer) things like rust, go, c#, node, etc.