¿Cómo lidiar correctamente con los binarys construidos localmente?

Tiendo a build binarys de fonts. Mi configuration habitual es la siguiente

$HOME/build -> this gets the sources $HOME/programs -> this is where the build happen, so where the binaries are 

Una vez hecho esto pongo lo siguiente en mi bashrc

 export MYNEWBINDIR = $HOME/programs/... export PATH=$MYNEWBINDIR:$PATH 

Mi pregunta es: ¿es la forma recomendada? Por ejemplo, podría simplemente crear un $HOME/bin local, unir todos los binarys y solo agregarlo a la ruta

Es más o less para que el individuo haga lo que desee, pero le recomendaría que deje los directorys ya utilizados por el sistema base o por cualquier administrador de packages solo, siempre. ¡Realmente no quiere confundir un administrador de packages al sobrescribir los files que ha instalado previamente! Así que definitivamente deja /bin solo.

En la mayoría de los sistemas, /usr/local debería ser un área segura para instalar cosas, aunque esto también lo usan los administradores de packages en algunos sistemas (FreeBSD y OpenBSD, por ejemplo, ya que consideran el software instalado desde puertos / packages como software local) .

Consulte también las inputs " Estándar de jerarquía del sistema de files " y " Sistema de files Unix " en Wikipedia.

Algunos Unices también tienen un manual de hier(7) que puede consultar. (El enlace va a la versión de OpenBSD, pero también está disponible al less en Ubuntu entre los Linux. En el caso de OpenBSD, documenta los directorys que el software del sistema conoce, por lo que no menciona /opt , por ejemplo).

Donde realmente construyes cosas realmente no importa, ya que es un directory que probablemente eliminarás cuando hayas terminado. Sin embargo, es una buena idea hacerlo lejos de los directorys de installation reales. Trabajé en sistemas que tenían treees fuente en /bin y /usr/local , que es extremadamente desorderado.

También recomendaría que realices una installation real para el software, en lugar de ejecutar los ejecutables desde el directory de compilation, a less que estés modificando la compilation. La recolección de los ejecutables en una sola location hace que tu PATH más limpia y más fácil de configurar, a less que realmente quieras un elemento PATH distinto para cada pieza de software, obviamente.


Opinión personal a continuación:

Para el software que construyo exclusivamente para mí, tiendo a usar una jerarquía privada en $HOME/local para las instalaciones.

Al comstackr progtwigs que usan las autotools de GNU y, por lo tanto, tienen un script de configure , esto es realmente fácil. Usted acaba de decir

 $ ./configure --prefix="$HOME/local" 

en la etapa de configuration, antes de make y make install .

Al comstackr progtwigs que utilizan CMake, uno puede lograr lo mismo mediante

 $ cmake -DCMAKE_INSTALL_PREFIX="$HOME/local" . 

antes de make y make install pasos de make install . Se puede tener el mismo efecto (por otros medios) al instalar modules Perl, etc.

Entonces, obviamente, tendrá que agregar $HOME/local/bin a su ruta …

Personalmente, uso GNU Stow también, lo que significa que realmente no especifico $HOME/local como el prefijo de installation, pero $HOME/local/stow/thing-2.1 cuando configuro el package de software thing-2.1 .

Después de instalar:

 $ cd "$HOME/local/stow" $ stow thing-2.1 

El contenido del directory $HOME/local/stow/thing-2.1/bin aparecerá (usando enlaces simbólicos) en $HOME/local/bin (y de manera similar para cualquier lib u otro directory instalado en thing-2.1 ).

Stow hace que sea muy fácil desinstalar el software. No hay necesidad de search cada pequeño file que instaló make install solo para desinstalar y eliminar un software, en lugar de solo

 $ cd "$HOME/local/stow" $ stow -D thing-2.1 $ rm -rf thing-2.1 
Intereting Posts