Can Gradle still build C with the new plugins? - c

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.

Related

Structure and dependencies of cross-platform CMake project

What is the right way to include external dependencies into CMake project? I've seen in some projects and dependencies, people add dependency as a git submodule, some find-scripts ExternalProject and package managers (conan).
So, the project is cross-platform (Windows, Android, in perspective iOS, macOS, Linux and others) and needs cross-compiling. The project is closed source, so user gets compiled binary. Cross-compiling is very important. Some of platforms require special dependencies (example: desktop needs GLFW).
One of solutions I think about: write a script (I think, python, because I need ability to compile project as in Windows as in Linux), which will compile all the dependencies for given platform (toolchain), put them in right folders and generate a script with paths to the libraries.

How to interpret suggestions when installing CakePHP via Composer?

When I try installing with command line:
composer self-update && composer create-project --prefer-dist cakephp/app my_app_name
I keep getting this message, which I didnt use to have, now which one is required, which one is not, do I have to download manually everytime?
cakephp/app suggests installing markstory/asset_compress (An asset compression plugin which provides file concatenation and a flexible filter system for preprocessing and minification.)
cakephp/app suggests installing dereuromark/cakephp-ide-helper (After baking your code, this keeps your annotations in sync with the code evolving from there on for maximum IDE and PHPStan compatibility.)
cakephp/app suggests installing phpunit/phpunit (Allows automated tests to be run without system-wide install.)
cakephp/cakephp suggests installing lib-ICU (The intl PHP library, to use Text::transliterate() or Text::slug())
symfony/console suggests installing symfony/event-dispatcher ()
symfony/console suggests installing symfony/lock ()
symfony/console suggests installing psr/log-implementation (For using the console logger)
m1/env suggests installing m1/vars (For loading of configs)
asm89/twig-cache-extension suggests installing psr/cache-implementation (To make use of PSR-6 cache implementation via PsrCacheAdapter.)
aptoma/twig-markdown suggests installing michelf/php-markdown (Original Markdown engine with MarkdownExtra.)
aptoma/twig-markdown suggests installing knplabs/github-api (Needed for using GitHub's Markdown engine provided through their API.)
ajgl/breakpoint-twig-extension suggests installing ext-xdebug (The Xdebug extension is required for the breakpoint to work)
ajgl/breakpoint-twig-extension suggests installing symfony/framework-bundle (The framework bundle to integrate the extension into Symfony)
ajgl/breakpoint-twig-extension suggests installing symfony/twig-bundle (The twig bundle to integrate the extension into Symfony)
psy/psysh suggests installing ext-pcntl (Enabling the PCNTL extension makes PsySH a lot happier :))
psy/psysh suggests installing ext-posix (If you have PCNTL, you'll want the POSIX extension as well.)
psy/psysh suggests installing ext-pdo-sqlite (The doc command requires SQLite to work.)
psy/psysh suggests installing hoa/console (A pure PHP readline implementation. You'll want this if your PHP install doesn't already support readline or libedit.)
These are only suggestions that may extend the functionality of already installed packages, but everything should work fine without them. For example monolog/monolog will suggest a couple of plugins that will allow logging into different backends. But monolog/monolog will work without them - you may not be able to log for example to Sentry, but monolog will still be usable without this feature.
So usually you can just ignore these suggestions. But you can take a few minutes to check what these suggested packages are actually doing - you can learn about new technologies and solutions that can make your app better and easier to maintain.
If you're really not interested in these suggestions, you can use --no-suggest switch to avoid displaying them on install/update/require:
composer install --no-suggest

Proprietary C extension for Ruby

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'

How to get WeasyPrint working with Google App Engine

I'm new to GAE, WeasyPrint and Python. I realise that WeasyPrint relies on quite a few dependences. I have had a look at the install documentation for Windows. But I cant seem to figure out how I would get it working on GAE. Is there no way to download an version with all the dependencies included and just copy it to my project folder?
Its not possible to run WeasyPrint directly on appengine. You should always read the docs on the dependencies. WeasyPrint is dependent on cairo and pango which are 'c' based libs. You can only run pure python libraries that you supply. There are some directly supported python libraries that do have some 'c' that are supported like PIL and libxml. But that isn't enough for WeasyPrint.

cmake vs gmake for qtcreator project

I am attempting to use QtCreator as an IDE for a straight C project. The reason is that I am comfortable with QtCreator and I want a visual IDE for stepping through this new project I am working on. My development box and my deployment box are different, but both of those have gmake on them. QtCreator requires cmake, which I dont mind putting on my development box, but my deployment box is not going to have cmake.
Am I OK to build my software on the Qt box, and be sure it will deploy on the deployment box?
Edit: to be clear, the existing code base already has a makefile structure going, and I'd rather not interrupt that. If I can set my project up to use those existing targets and such it would be great.
If your project is using CMake as build system, then you should have it installed on the machine you are building. You can't pregenerate Makefile's and then just run make on the other box.
Well, you actually can, but then you will probably need same compiler versions, libs/headers located in same paths and etc. So generally it's not good idea.
As for deploying already compiled binaries - it have no relation to CMake. The general rule there is that you should have same shared libraries on both machines. Linking your project statically allows deploying single fat executable/library, without any additional dependencies.

Resources