Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español Usually, a .NET project consumes standard and third-party libraries from nuget.org . For context, NuGet is .NET's de facto package manager, like npm for Javascript, PyPI for Python, Maven for Java, Conan for C++, and so on. It's common practice for an organization to own a NuGet repository hosted in a binary hosting service such as Artifactory or Nexus . If the organization develops its own libraries, they will be hosted in that particular repository. This way, libraries can be used across different development teams inside the organization, and also beyond it if libraries are chosen to be made public. This is all well and good, but sometimes the hosting service goes down, or it is desirable to tinker with the libraries locally before deploying them. In scenarios like these, it's helpful to have an extra NuGet source that lives in the developer's machine and can be used when building and developing .NET applications. T...

Versión en inglés / English version Típicamente, un proyecto .NET consume bibliotecas estándar y de terceros a través de nuget.org . Contextualizando un poco, NuGet es el gestor de paquetes o ( package manager ) de facto del ecosistema .NET, como npm para Javascript, PyPI para Python, Maven para Java, Conan para C++, etcétera. Es una práctica bastante establecida que las organizaciones tengan un repositorio NuGet privado alojado en un servicio de hosting de binarios como Artifactory o Nexus . Si la organización desarrolla sus propias bibliotecas, las alojará en dicho repositorio. Así, podrán ser reusadas entre distintos equipos de desarrollo dentro de la organización, e incluso fuera de la misma si se opta por hacerlas públicas. Todo esto está muy bien, pero a veces el servicio de alojamiento de binarios se cae, o se desea modificar las bibliotecas localmente antes de desplegarlas. En escenarios así, resulta útil tener una fuente NuGet adicional alojada en la máquina de...

Spanish version / Versión en Español In order to explore the concepts from the first post in a more practical fashion, today we will look at a step by step guide for creating a C programming language project built and tested using Autotools . 1: Application entry point This will be src/main.c . It's typical to have a src directory for source code, because when the project grows, it will probably need other top-level directories such as man for man pages , data for data files, and so on. src/main.c #include <config.h> #include <stdio.h> int main (void) { puts("Hello World!"); puts("This is " PACKAGE_STRING "."); return 0; } Including config.h is necessary because that's where PACKAGE_STRING will be defined. In turn, config.h will be generated by Autotools. 2: Top-level configure.ac file All configure.ac files contain Autoconf instructions which control the generation of the configure script. These...

Versión en inglés / English version Para bajar a tierra los conceptos del primer post , hoy seguiremos paso a paso la creación de un proyecto en lenguaje C usando Autotools como sistema de build . 1: Punto de entrada En primer lugar, se crea el punto de entrada del programa, src/main.c . Es típico tener un directorio src para el código fuente, ya que al evolucionar el proyecto, probablemente se agreguen directorios como man para páginas de ayuda ( man pages ), data para archivos de datos, etc. src/main.c #include <config.h> #include <stdio.h> int main (void) { puts("Hello World!"); puts("This is " PACKAGE_STRING "."); return 0; } La inclusión de config.h viene dada porque ese archivo será generado por Autotools, y es donde estará definido PACKAGE_STRING. 2: Archivo configure.ac raíz Los archivos configure.ac contienen instrucciones Autoconf que controlan la generación del script configure . Dichas instru...

Spanish version / Versión en Español First thing first: what are GNU Autotools , and what are they used for? The moniker "GNU Autotools" refers to a collection of software packages: Autoconf , Automake and Libtool . These packages include programs aimed at standardizing and automating the build, test, release and installation processes across multiple platforms. In that sense, it shares a lot of goals and purpose with other tools such as CMake . Most of the GNU software is built using Autotools; git is a famous example. More specifically, what the Autotools do is generate configure scripts and Makefiles from certain configuration files. When generating these files, portability across different platforms is considered in order to allow the package to be built in as many different environments as possible. A user's perspective In this context, we will consider a user a person who downloaded a source tarball for some package, and wants to build it and inst...

Versión en inglés / English version En primer lugar: ¿qué son las Autotools de GNU , y para qué sirven? El nombre "GNU Autotools" se refiera a una colección de paquetes de software : Autoconf , Automake y Libtool . Estos paquetes contienen programas cuyo objetivo es estandarizar y automatizar los procesos de compilación, prueba, entrega e instalación a través de distintas plataformas. En ese sentido, comparte propósito con otras herramientas como CMake . Gran parte de el software de GNU ha sido creado con Autotools; git es un ejemplo célebre. Más específicamente, lo que las Autotools hacen es generar scripts y Makefiles a partir de archivos de configuración de entrada escritos por el desarrolador. Al generar estos scripts y Makefiles , se considera la portabilidad a través de distintas plataformas a fin de que el paquete funcione en la mayor cantidad de entornos posible. La perspectiva del usuario En este contexto, se considerará al usuario como una per...