I've created a nimble library package as per the documentation. When I try to build it using nimble build I get the following error.
Error: Nothing to build. Did you specify a module to build using the bin key in your .nimble file?
I can do this and it does fix the error but according to the documentation adding the bin key to the .nimble file turns my package into a binary package.
Other things I have tried:
Use nimble install: This does not appear to verify that my code will actually compile and will happily install anything to the local package directory (I added a C# class to my .nim file, for example, and it was successfully installed).
Use nimble c: This works but I have to pass in the path to the nim file I want to compile and the binDir entry in the .nimble file is ignored resulting in the output being placed in the same directory as the file being built. This complicates the development cycle because I have to manually clean up after the compiler.
Use the compiler directly. This is pretty much the same as the previous option with the same flaws.
I guess I could also create a separate .nim file and import my library after it is installed but this is a big overhead for just wanting to verify that a package in the early stages of development will actually compile.
I just want to be able to verify that the source code in my library package is syntactically correct and will compile. How is this meant to be done for library packages?
From your provided link to the nimble package manager documentation I have the feeling that
https://github.com/nim-lang/nimble#tests
is what you are looking for. But I have never used the test command, so I am not sure. I do my test manually still, I read the nimble docs maybe 4 years ago and can not really remember. And currently there is much package manager related work going on, I heard there is a new, alternative package manager called nimph, and from a forum thread I think I read something that nimble is going to change and improve also. Maybe you should consider subscribing to the Nim forum, that is the place where the bright Nim devs are. Well, at least a few of them.
Related
I've installed and executed (with nodejs) a package from npm: https://www.npmjs.com/package/openssl.js
Somehow I didn't realize that it hasn't a good reputation (almost no activity/stars on twitter, github). Now I'm afraid that it is a scam. The worst case would be that is stealing/encrypting my data or something like that.
I've checked the processes, I/O and network in the activity monitor but nothing interesting.
But I would like to have more confidence that everything is okay.
Since it is a Wasm file I cannot just check the source code.
I've tried to decompile with this tool: https://github.com/WebAssembly/wabt but it gives me for all binaries in that project this error: error: #0x00000004: bad magic value.
Maybe because in the README of the openssl.js package they claim it is build with wasienv toolchain?
Another idea would be install a honeypot and run the same commands in the honeypot. But which honeypot is suitable for this?
// edit
I was able to run wasm2c on this file: src/raw-wasm/openssl.wasm.
But how can I ensure there was no network interactivity?
Here are the first lines of the output: https://pastebin.com/YYHecFAC
I am getting into a position where I have to use other people code for projects, for example openTLD. I want to change some of the code to give it more functionality and use it in a diffrent way. What I have found is that many people have packaged their files in such a way that you are supposed to use
cmake
and then
make
and sometimes after that
make install
I don't want to install the software on my system. What I am looking to do is get these peoples code to a point where I can add to it in Eclipse or even just using Nano and then compile it.
At what point is the code in a workable/usable state. Can I use it after doing cmake or do I need to also call make? Is my thinking correct that it would be better to edit the code after calling cmake as opposed to before? I am not going to want my finished code to be cross platform supported, it will only be on Linux. Is it easer to learn cmake and edit the code befor running cmake as opposed to not learning cmake and using the code afterwards, if that is possible?
You question is a little open ended.
Looking at the opentld project, there is a binary and a library available for use. If you are interested in using the binary in your code, you need to download the executables(Linux executables are not posted). If you are planning to use the library, you have two options. Either you use the pre-built library or build it during your build process. You would include the header files in your custom application and link with the library.
If you add more details, probably others can pitch in with new answers or refine the older ones.
I was installing gperftools:
https://code.google.com/p/gperftools/
Everything worked, and I see that the project links to /usr/local/lib
I'd like to put the library in a folder local to my project, instead.
The reasoning behind this is that I'm putting the project on different machines, and I just need to link against the libprofiler and libtcmalloc libraries, instead of the entire package, that also comes with the pprof and such.
The machines also have different architectures, so I actually need to build into that directory, instead of copy-pasting over
Is this a trivial thing to do?
gperftools uses autoconf/automake, so you can do
./configure --prefix=/path/to/whereever
make
make install
This works for all autotools projects, unless they are severely broken.
On that note, it is generally a good idea to read the INSTALL file in a source tree to find out about this sort of stuff. There is one in the gperftools sources, and this is documented there.
I'm a good Java programmer, albeit the first languages I learnt were C/C++. Anyway, for work reasons, I switched to Java and web languages. Sometimes I get interested in this or that Linux project, usually coming as a git or svn repository... The problem is that I usually clone the repo, I try to configure it, I install all the needed libraries (and this takes ages), maybe finally I succeed... but then make fails or configure itself fails, complaining about some tool that is missing. Or maybe I installed two versions of the same library and the configure script gets the wrong one, or boring problems like this.
Anyway, I see loads of people using those tools everyday, so it must not be so difficult after all!
Can you point out resources that may help in the first steps?
Thanks
What you are referring to are known as autotools and make
autotools are used to generate scripts and build files that can be used to build as well as install a program/package/software (whatever you call it)
Here is wikipedia link for the GNU build system in general.
And refer to this link for details about the autotools and related stuff
It may take longer, but if you are interested in how to fix those problems yourself I recommend learning how autoconf and automake work. I made a positive experience with the book "Autotools: a practitioner's guide to Autoconf, Automake and Libtool". I read the dead-tree version but it is also available online: http://fsmsh.com/2753.
We are using SCons for all our build need, and we would like to distribute a library in open source.
Now most softwares uses ./configure, make and make install as build mechanism, we were wondering how we should bundle our library.
We have the following solutions:
Just bundle like the way it is, requiring scons to build.
Add a dummy configure and makefile that just call scons.
Add autoconf and a makefile.
How it is perceived to get a software requiring python and scons to build?
I think it depends largely on your target audience (ie, users who can easily install scons if they don't have it, or ones who can't), but if you are distributing source at all then presumably your users are happy compiling things, and they can install scons too (and python if for some obscene reason they don't have it already)
Also, if you are worried about people not being able to build it, you should probably be distributing a binary package anyway.
If your library is cross-platform and can be compiled on Windows too, then using scons is the right choice.
Another option would be to include the scons-local version in the package. This reduces the dependencies to just python.