I've written some proprietary business logic in C that I want to run from Ruby. I attempted to write it as a gem that was simply included by Bundler from a path internal to the main project; however, Bundler "doesn't build native extensions in that case" (tmoore in the #bundler irc channel).
I would rather not create a separate private repository for this C extension gem. I would also rather not precompile native versions for all the environments. RubyInline does not appear to be an option because the C is more than just a couple functions, makes heavy use of pointers to structs passed between functions, etc.
Are there any options for building C into a project such that the C will be compiled on the target machine via standard bundle installation?
Thanks to tmoore in the #bundler irc channel for pointing me to the following:
http://bundler.io/v1.5/man/gemfile.5.html#PATH-path-
https://github.com/bundler/bundler/issues/1679#issuecomment-11162403
From the former:
Unlike :git, bundler does not compile C extensions for gems specified
as paths.
And from the latter:
I think I'm going to go with "please use git gems if you need to
compile extensions". :path, as an option, is a way to add directories
that you are managing manually to the load path. If you need an
extension built in those directories, you should be doing it yourself
as part of managing that directory manually. :)
So that's the official word. If you want Bundler to compile a proprietary extension, load your extension gem from a private Git repository. (This was helpful: https://gist.github.com/masonforest/4048732.) In order to avoid overly wide privileges, you can:
create a new Github account dedicated to your private repos
grant it read only access to only your private extension repos
create an oauth token for that dedicated Github user: https://help.github.com/articles/creating-an-access-token-for-command-line-use/
incorporate that oauthtoken into your git url in your gemfile:
gem 'your_gem_name', git:
'https://your_oauth_token:x-oauth-basic#github.com/account/project.git'
Related
When I search for how to build C with Gradle, official docs come up with the following info, explicitly mentioning C:
The native software plugins add support for building native software components, such as executables or shared libraries, from code written in C++, C and other languages.
But also this info:
The (...) plugins mentioned in this chapter will eventually be deprecated and removed. We recommend new projects looking to build C++ applications and libraries use the newer replacement plugins.
The linked general docs for the replacement plugins only mention C++, and the dedicated plugin docs for cpp-application and cpp-library are even explicit about C++ file extensions.
However, a third-party site states:
Gradle is a build automation system that provides plugins to build C/C++ libraries and applications. (...) based on cpp-application and cpp-library plugins (...)
So is it still possible to build pure C applications and libraries with Gradle plugins that are not being retired, particularly with cpp-application and cpp-library?
In case the answer is somehow obvious, please note I am not a C/C++ developer.
I am using Quicklisp to load libraries in my Common Lisp project and
I need to load a customised version of some library instead of the version provided by Quicklisp.
The customised version of the library is stored in the local projects directory from Quicklisp and local projects have been registered. However Quicklisp still tries to load its own version of the library.
How can arrange for Quicklisp to prefer the customised of the library? (Side question: how can I ask Quicklisp which location it will use to load a library?)
If the project's system file is loadable with ASDF, it is loaded in preference to the Quicklisp-provided version. The easiest way to do that is to put the project's sources into ~/quicklisp/local-projects/ (or wherever your quicklisp is installed rather than ~/quicklisp/) and run (ql:register-local-projects). But other methods, like updating the ASDF registry configuration and putting the project somewhere known to ASDF via the registry, also work.
To find out where Quicklisp is loading your project, you can use (ql:where-is-system "system-name").
Remember that
The local-projects mechanism is configured through a special variable ql:*local-project-directories*. By default, it includes only the local-projects subdirectory in the Quicklisp install directory, but you can add or remove directories at any time to have more places scanned for systems.
To disable the local-projects mechanism entirely, set ql:*local-project-directories* to NIL.
(Quicklisp News Blog)
I have a C project using autotools and make to build my project. I need to use code that as far as I can tell is only available on github. What is the best practice for including this code in my project? How would I do it?
This is the code I want to use
The best I can think of is to probably use Git Submodules so that you bundle your dependencies with your repository without having them to be inside your repository. This will provide you with 2 advantages, your library dependency will always be (latest), your git repository won't be bloated of all the unnecessary data and objects that the library would have brought. Make sure to build with the lib and to query the user if he does not have it on his system.
C does not have any native dependency manager.
If any tool could do something like you want and for basically anything, you could look into Conda
As given in mega-manual,
4.2.2.2. Creating the Project
You can create two types of projects: Autotools-based, or
Makefile-based. This section describes how to create Autotools-based
projects from within the Eclipse IDE. For information on creating
Makefile-based projects in a terminal window, see the section "Using
the Command Line" in the Yocto Project Application Developer's Guide.
I want to deploy a separate binary package, I don't want to create an image including my package. Isn't it possible to build a binary package like .ipk .deb .rpm using poky?
Yes, packages are always created. Autotools and Makefiles are for configuring/building software, so not really related to the question.
Use the PACKAGE_CLASSES variable in your configuration to select the package types you want to build with Yocto/OpenEmbedded. When you "bitbake recipe-name" the packages are built in the deploy directories under recipe WORKDIR.
Please don't expect the packages to be compatible with some other operating system though: they will be tailored for your specific configuration. If you already have an image running exactly that configuration, then it should be fine.
I am moving from Netbeans to Eclipse (on Ubuntu 12.0.4). I have a C application that consists of several sub projects which are libraries (shared and static), as well as stand alone executables.
I can't figure out how to create a 'parent' project foo, which contains component projects
foobar
foofoo
barfoo
barbar
Ideally, I want all the 'component projects' to be created under the folder foo, so that I have a directory structure like this:
/path/to/foo/foobar/ (contains foobar project files)
/path/to/foo/foofoo/ (contains foofoo project files)
/path/to/foo/barfoo/ (contains barfoo project files)
/path/to/foo/barbar/ (contains barbar project files)
Does anyone know how I can achieve this structure using Eclipse as IDE (with CDT)?
Last but not the least, I intend to create my C modules using the Autotools option. Will the generated files for Autotools be automatically updated as I add new header/source to a module - or do I need to manually maintain the Autotool files?
Friend,
I think there is no the "parent" C project. You can create a normal C project in IDE and add all dependencies into sub-folders. Then tell compiler your build procedure via Makefile. I think it's easy way as you have had experience on C application.
About autotools, once you update/add/remove your project file, I think you need to modify your Makefile to reflect your change and do clean and rebuild your project.
For other C build tools, you can use buildroot if you'd like.
The best way I can think to do this in eclipse is to create a separate workspace for the project e.g. foo, and then add the sub-projects (foobar, foofoo, etc...) as projects. This is generally a better approach to take with eclipse, instead of a single monolithic workspace. I don't know what the specific dependency structure for the sub-projects looks like, but you should be able to express it simply by using eclipse project properties. This can include a rollup executable sub-project that depends on the libraries.
Unfortunately, I'm not sure if eclipse cdt will maintain autotools files. However if not, it should be relatively easy to integrate and use some of the autotools binaries such as autoscan, and autoheader into the eclipse build commands.
At first you need to a working directory, Then you should new project, Then per file or per class (according to C++ or C ) append your files, it's much safe way. another way is not clean, i have experience. don't use them.