Acción
Un comando para ejecutar durante la compilación, por ejemplo, una llamada a un compilador que toma artefactos como entradas y los produce como salidas. Incluye metadatos como los argumentos de la línea de comandos, la clave de acción, las variables de entorno y los artefactos de entrada y salida declarados.
Consulta también: Documentación sobre las reglas
Caché de acciones
Una caché en disco que almacena una asignación de las acciones ejecutadas a los resultados que crearon. La clave de caché se conoce como clave de acción. Un componente principal del modelo de incrementalidad de Bazel. La caché se almacena en el directorio base de salida y, por lo tanto, sobrevive a los reinicios del servidor de Bazel.
Gráfico de acción
Un gráfico en la memoria de las acciones y los artefactos que estas acciones leen y generan. El gráfico puede incluir artefactos que existen como archivos de origen (por ejemplo, en el sistema de archivos) y artefactos intermedios y finales generados que no se mencionan en los archivos BUILD. Se produce durante la fase de análisis y se usa durante la fase de ejecución.
Consulta de grafo de acción (aquery)
Una herramienta de consulta que puede consultar sobre las acciones de compilación. Esto permite analizar cómo lo hacen las reglas de compilación en las compilaciones de trabajo reales.
Tecla de acción
La clave de caché de una acción. Se calcula en función de los metadatos de la acción, que pueden incluir el comando que se ejecutará en la acción, las marcas del compilador, las ubicaciones de la biblioteca o los encabezados del sistema, según la acción. Permite que Bazel almacene en caché o invalide acciones individuales de manera determinista.
Fase de análisis
La segunda fase de una compilación. Procesa el gráfico de destino especificado en archivos BUILD para producir un gráfico de acciones en la memoria que determina el orden de las acciones que se ejecutarán durante la fase de ejecución. Esta es la fase en la que se evalúan las implementaciones de reglas.
Artifact
Un archivo de origen o un archivo generado. También puede ser un directorio de archivos, conocido como artefactos de árbol.
Un artefacto puede ser una entrada para varias acciones, pero solo lo debe generar una acción, como máximo.
Se puede abordar un artefacto que corresponde a un destino de archivo mediante una etiqueta.
Aspecto
Un mecanismo para que las reglas creen acciones adicionales en sus dependencias. Por ejemplo, si el destino A depende de B, se puede aplicar un aspecto en A que desvía hacia arriba un perímetro de dependencia hasta B y ejecute acciones adicionales en B para generar y recopilar archivos de salida adicionales. Estas acciones adicionales se almacenan en caché y se reutilizan entre los destinos que requieren el mismo aspecto. Se crea con la función aspect() de la API de Starlark Build. Se puede usar, por ejemplo, a fin de generar metadatos para IDE y crear acciones de análisis con lint.
Consulta también: Documentación sobre los aspectos
Aspecto en aspecto
Un mecanismo de composición en el que los aspectos se pueden aplicar a los resultados de otros aspectos. Por ejemplo, un aspecto que genera información para que los IDE la usen se puede aplicar sobre un aspecto que genera archivos .java a partir de un proto.
Para que un aspecto A se aplique sobre el aspecto B, los proveedores que B anuncia en su atributo provides deben coincidir con lo que A declara que desea en su atributo required_aspect_providers.
Atributo
Un parámetro para una regla, que se usa para expresar información de compilación por destino.
Entre los ejemplos, se incluyen srcs, deps y copts, que declaran respectivamente los archivos de origen, las dependencias y las opciones del compilador personalizado de un destino. Los atributos específicos disponibles para un objetivo determinado dependen de su tipo de regla.
Bazelrc
El archivo de configuración de Bazel se usa para cambiar los valores predeterminados de las marcas
de inicio y las marcas de comando, y para definir grupos
comunes de opciones que, luego, se pueden configurar juntos en la línea de comandos de Bazel con
una marca --config. Bazel puede combinar la configuración de varios archivos de Bazelrc
(en todo el sistema, por espacio de trabajo, por usuario o desde una ubicación personalizada), y un
archivo bazelrc también puede importar la configuración de otros archivos bazelrc.
Blaze
Es la versión interna de Google de Bazel. el principal sistema de compilación de Google para su repositorio mono.
Archivo BUILD
Un archivo BUILD es el archivo de configuración principal que le indica a Bazel qué software
debe compilar, cuáles son sus dependencias y cómo compilarlas. Bazel
toma un archivo BUILD como entrada y lo usa para crear un gráfico de dependencias
y derivar las acciones que deben completarse para compilar resultados de software
intermedios y finales. Un archivo BUILD marca un directorio y cualquier subdirectorio que no contenga un archivo BUILD como paquete, y puede contener destinos creados por reglas. El archivo también puede tener el nombre BUILD.bazel.
Archivo BUILD.bazel
Consulta Archivo BUILD. Tiene prioridad sobre un archivo BUILD en el mismo directorio.
Archivo .bzl
Es un archivo que define reglas, macros y constantes escritas en Starlark. Luego, estos se pueden importar a archivos BUILD con la función load().
Gráfico de compilación
El gráfico de dependencias que Bazel construye y recorre para realizar una compilación. Incluye nodos como objetivos, objetivos configurados, acciones y artefactos. Una compilación se considera completa cuando todos los artefactos de los que depende un conjunto de destinos solicitados se verifican como actualizados.
Configuración de la compilación
Una configuración definida por Starlark. Las transiciones pueden establecer configuraciones de compilación para cambiar la configuración de un subgrafo. Si se expone al usuario como una marca de línea de comandos, también conocida como marca de compilación.
Compilación limpia
Una compilación que no usa los resultados de compilaciones anteriores. Por lo general, esto es más lento que una compilación incremental, pero se considera que es más correcto. Bazel garantiza que las compilaciones incrementales y limpias siempre sean correctas.
Modelo cliente-servidor
El cliente de línea de comandos de bazel inicia de forma automática un servidor en segundo plano en la
máquina local para ejecutar los comandos de Bazel. El servidor persiste en todos los comandos, pero se detiene automáticamente después de un período de inactividad (o de manera explícita mediante el cierre de Bazel). Dividir Bazel en un servidor y un cliente ayuda a amortizar el tiempo de inicio de JVM y admite compilaciones incrementales más rápidas, ya que el gráfico de acciones permanece en la memoria de todos los comandos.
Comando
Se usa en la línea de comandos para invocar diferentes funciones de Bazel, como bazel
build, bazel test, bazel run y bazel query.
Marcas de comando
Un conjunto de marcas específicas de un comando. Las marcas de comando se especifican después del comando (bazel build <command flags>). Las marcas se pueden aplicar a uno o más comandos. Por ejemplo, --configure es una marca exclusiva para el comando bazel sync, pero --keep_going se aplica a sync, build, test y otros elementos. Las marcas suelen usarse para fines de configuración, por lo que los cambios en los valores de las marcas pueden hacer que Bazel invalide los gráficos en la memoria y reinicie la fase de análisis.
Configuración
Información fuera de las definiciones de regla que afecta la manera en que las reglas generan acciones. Cada compilación tiene al menos una configuración que especifica la plataforma de destino, las variables de entorno de acción y las marcas de compilación de la línea de comandos. Las transiciones pueden crear configuraciones adicionales, como para herramientas de host o compilación cruzada.
Consulta también: Configuraciones
Recorte de configuración
El proceso de incluir solo las partes de la configuración que un objetivo realmente necesita. Por ejemplo, si compilas el objeto binario //:j de Java con la dependencia //:c de C++, es un desperdicio incluir el valor de --javacopt en la configuración de //:c, ya que cambiar --javacopt rompe innecesariamente la capacidad de almacenamiento en caché de la compilación de C++.
Consulta configurada (cquery)
Una herramienta de consulta que realiza consultas sobre destinos configurados (después de que se completa la fase de análisis) Esto significa que select() y las marcas de compilación (como --platforms) se reflejan con precisión en los resultados.
Consulta también: documentación de cquery
Destino configurado
El resultado de evaluar un objetivo con una configuración. Para la fase de análisis, esto se logra combinando las opciones de la compilación con los destinos que se deben compilar.
Por ejemplo, si //:foo compila para dos arquitecturas diferentes en la misma
compilación, tendrá dos destinos configurados: <//:foo, x86> y <//:foo, arm>.
Precisión
Una compilación es correcta cuando su salida refleja fielmente el estado de sus entradas transitivas. Para lograr compilaciones correctas, Bazel se esfuerza por ser hermético y reproducible, además de hacer que el análisis de la compilación y la ejecución de acciones sean deterministas.
Dependencia
Un perímetro dirigido entre dos objetivos Un //:foo de destino tiene una dependencia de //:bar de destino si los valores del atributo de //:foo contienen una referencia a //:bar. //:foo tiene una dependencia de acciones en //:bar si una acción de //:foo depende de un artefacto de entrada creado por una acción en //:bar.
Depset
Es una estructura de datos para recopilar datos sobre dependencias transitivas. Se optimizó para que la combinación de dependencias sea eficiente en el tiempo y el espacio, ya que es común tener dependencias muy grandes (cientos de miles de archivos). Se implementa para hacer referencia de manera recursiva a otras salidas por razones de eficiencia del espacio. Las implementaciones de reglas no deben "compactar" los repositorios convirtiéndolos en listas, a menos que la regla esté en el nivel superior del gráfico de compilación. Compactar los depsets grandes genera un gran consumo de memoria. También se conocen como conjuntos anidados en la implementación interna de Bazel.
Consulta también: Documentación de Depset
Caché de disco
Un almacén local de BLOB en el disco para la función de almacenamiento en caché remoto. Se puede usar en conjunto con un almacén de BLOB remoto real.
Distdir
Un directorio de solo lectura que contiene archivos que Bazel recuperaría de Internet mediante reglas de repositorio. Permite que las compilaciones se ejecuten por completo sin conexión.
Ejecución dinámica
Es una estrategia de ejecución que selecciona entre la ejecución local y remota según varias heurísticas y usa los resultados de ejecución del método exitoso más rápido. Algunas acciones se ejecutan más rápido de forma local (por ejemplo, la vinculación) y otras son más rápidas de forma remota (por ejemplo, la compilación altamente paralelizable). Una estrategia de ejecución dinámica puede proporcionar los mejores tiempos de compilación incrementales y limpios posibles.
Fase de ejecución
La tercera fase de una compilación. Ejecuta las acciones en el gráfico de acciones creado durante la fase de análisis. Estas acciones invocan ejecutables (compiladores, secuencias de comandos) para leer y escribir artefactos. Las estrategias de generación controlan cómo se ejecutan estas acciones: de forma local, remota, dinámica, en zona de pruebas, Docker, etcétera.
Raíz de ejecución
Un directorio en el directorio base de salida del lugar de trabajo en el que las acciones locales se ejecutan en compilaciones que no están en la zona de pruebas. El contenido del directorio son, en su mayoría, symlinks de artefactos de entrada del lugar de trabajo. La raíz de ejecución también contiene symlinks a repositorios externos como otras entradas y el directorio bazel-out para almacenar resultados. Se preparan durante la fase de carga mediante la creación de un bosque de symlink de los directorios que representan el cierre transitivo de los paquetes de los que depende una compilación. Se puede acceder con bazel info
execution_root en la línea de comandos.
Archivo
Consulta Artefacto.
Hermeticidad
Una compilación es hermética si no hay influencias externas en sus operaciones de compilación y prueba, lo que ayuda a garantizar que los resultados sean deterministas y correctos. Por ejemplo, las compilaciones herméticas generalmente no permiten el acceso de red a las acciones, restringen el acceso a entradas declaradas, usan marcas de tiempo y zonas horarias fijas, restringen el acceso a variables de entorno y usan valores iniciales fijos para generadores de números aleatorios.
Compilación incremental
Una compilación incremental reutiliza los resultados de compilaciones anteriores para reducir el tiempo de compilación y el uso de recursos. La verificación de dependencias y el almacenamiento en caché tienen como objetivo producir resultados correctos para este tipo de compilación. Una compilación incremental es lo opuesto a una compilación limpia.
Etiqueta
Un identificador para un objetivo. Una etiqueta completamente calificada, como //path/to/package:target, consiste en // para marcar el directorio raíz del lugar de trabajo, path/to/package como el directorio que contiene el archivo BUILD que declara el destino y :target como el nombre del destino declarado en el archivo BUILD antes mencionado. También puede tener el prefijo @my_repository//<..> para indicar que el destino está declarado en un ]repositorio externo] llamado my_repository.
Fase de carga
Primera fase de una compilación en la que Bazel analiza los archivos WORKSPACE, BUILD y .bzl para crear paquetes. En esta fase, se evalúan las macros y ciertas funciones, como glob(). Intercalado con la segunda fase de la compilación, la fase de análisis, para crear un grafo de destino.
Macro
Un mecanismo para componer varias declaraciones de destino rule juntas en una sola función Starlark. Permite la reutilización de patrones comunes de declaración de reglas en archivos BUILD. Se expande a las declaraciones de objetivo de la regla subyacente durante la fase de carga.
Consulta también: Documentación de macros
Mnemónico
Es una cadena corta y legible por humanos que el autor de la regla selecciona para comprender rápidamente lo que hace una acción en la regla. Los mnemónicos se pueden usar como identificadores para las selecciones de estrategias de generación. Algunos ejemplos de mnemotecnias de acciones son Javac de reglas de Java, CppCompile de reglas de C++ y AndroidManifestMerger de reglas de Android.
Reglas nativas
Las reglas que se compilan en Bazel y se implementan en Java. Estas reglas aparecen en los archivos .bzl como funciones del módulo nativo (por ejemplo, native.cc_library o native.java_library). Las reglas definidas por el usuario (no nativas) se crean con Starlark.
Base de salida
Un directorio específico de workspace para almacenar archivos de salida de Bazel. Se usa para separar los resultados del árbol fuente del lugar de trabajo. Se encuentra en la raíz del usuario de salida.
Grupos de salida
Un grupo de archivos que se espera que se compile cuando Bazel termine de compilar un
destino. Las reglas colocan sus resultados habituales en el "grupo de salida predeterminado" (p. ej., el archivo .jar de un java_library, .a y .so para objetivos cc_library). El grupo de salida predeterminado es aquel cuyos artefactos se compilan cuando se solicita un destino en la línea de comandos.
Las reglas pueden definir más grupos de salida con nombre que se pueden especificar de forma explícita en archivos BUILD (regla filegroup) o en la línea de comandos (marca --output_groups).
Raíz de usuario de salida
Un directorio específico del usuario para almacenar los resultados de Bazel. El nombre del directorio deriva del nombre de usuario del sistema del usuario. Evita las colisiones de archivos de salida si varios usuarios compilan el mismo proyecto en el sistema al mismo tiempo. Contiene subdirectorios que corresponden a las salidas de compilación de lugares de trabajo individuales, también conocidos como bases de salida.
Paquete
Es el conjunto de destinos definido por un archivo BUILD. El nombre de un paquete es la ruta de acceso del archivo BUILD relativa a la raíz del lugar de trabajo. Un paquete puede contener subpaquetes o subdirectorios con archivos BUILD, lo que forma una jerarquía de paquetes.
Grupo de paquetes
Un objetivo que representa un conjunto de paquetes Se suele usar en los valores del atributo visibility.
Plataforma
Es un “tipo de máquina” involucrado en una compilación. Esto incluye la máquina en la que se ejecuta Bazel (la plataforma “host”), las herramientas de compilación de las máquinas se ejecutan en las plataformas “ejecutivas” y las máquinas para los que se compilan los destinos de las máquinas (“plataformas de destino”).
Proveedor
Es un esquema que describe una unidad de información para pasar entre objetivos de la regla junto con las relaciones de dependencia. Por lo general, contiene información como opciones del compilador, archivos de origen o de salida transitivos y metadatos de compilación. Por lo general, se usa junto con depsets para almacenar de manera eficiente los datos transitivos acumulados. Un ejemplo de un proveedor integrado es DefaultInfo.
Consulta también: Documentación para proveedores
Consulta (concepto)
Es el proceso de analizar un gráfico de compilación para comprender las propiedades de destino y las estructuras de dependencia. Bazel admite tres variantes de consulta: query, cquery y aquery.
query (comando)
Una herramienta de consulta que opera sobre el grafo de destino posterior a la fase de carga de la compilación. Este proceso es relativamente rápido, pero no se pueden analizar los efectos de select(), las marcas de compilación, los artefactos ni las acciones de compilación.
Consulta también: Instructivo para consultas, Referencia de consultas
Caché del repositorio
Una caché compartida de contenido direccionable de archivos descargados por Bazel para compilaciones,
que se puede compartir entre espacios de trabajo. Habilita compilaciones sin conexión después de la descarga inicial. Por lo general, se usa para almacenar en caché los archivos descargados a través de reglas de repositorio, como http_archive, y APIs de reglas de repositorio, como repository_ctx.download. Los archivos se almacenan en caché solo si se especifican sus sumas de verificación SHA-256 para la descarga.
Reproducibilidad
La propiedad de una compilación o prueba de que un conjunto de entradas a la compilación o la prueba siempre producirá el mismo conjunto de salidas siempre, sin importar el tiempo, el método o el entorno. Ten en cuenta que esto no implica necesariamente que los resultados sean correctos o que sean los deseados.
Regla
Un esquema para definir destinos de la regla en un archivo BUILD, como cc_library. Desde la perspectiva del autor de un archivo BUILD, una regla consta de un conjunto de atributos y lógica de caja negra. La lógica le indica al destino de la regla cómo producir artefactos de salida y pasar información a otros destinos de la regla. Desde la perspectiva de los autores de .bzl, las reglas son la forma principal de extender Bazel para admitir nuevos lenguajes de programación y entornos.
Se crea una instancia de las reglas para producir objetivos de reglas en la fase de carga. En la fase de análisis, los objetivos comunican información a sus dependencias descendentes en forma de proveedores y registran acciones que describen cómo generar sus artefactos de salida. Estas acciones se ejecutan en la fase de ejecución.
Consulta también: Documentación sobre las reglas
Objetivo de la regla
Un objetivo que es una instancia de una regla. Compara esto con los objetivos de archivos y los grupos de paquetes. No se debe confundir con la regla.
Archivos de ejecución
Las dependencias del entorno de ejecución de un destino ejecutable. Por lo general, el ejecutable es el resultado ejecutable de una regla de prueba, y los archivos de ejecución son dependencias de datos del entorno de ejecución de la prueba. Antes de invocar el archivo ejecutable (durante la prueba de Bazel), Bazel prepara el árbol de archivos de ejecución junto con el ejecutable de prueba según la estructura de su directorio de origen.
Consulta también: Documentación de archivos de ejecución
Zona de pruebas
Es una técnica para aislar una acción en ejecución dentro de una raíz de ejecución restringida y temporal, lo que ayuda a garantizar que no lea entradas no declaradas ni escriba salidas no declaradas. Las zonas de pruebas mejoran en gran medida la hermeticidad, pero, por lo general, tienen un costo de rendimiento y requieren compatibilidad con el sistema operativo. El costo de rendimiento depende de la plataforma. En Linux, no es significativo, pero en macOS puede hacer que la zona de pruebas sea inutilizable.
Skyframe
Skyframe es el marco de trabajo de evaluación incremental, funcional y paralelo principal de Bazel.
Estampado
Una función para incorporar información adicional en artefactos compilados por Bazel. Por ejemplo, se puede usar para el control de la fuente, el tiempo de compilación y otra información relacionada con el lugar de trabajo o el entorno para las compilaciones de lanzamiento.
Habilítalo a través de la marca --workspace_status_command y las reglas que admiten el atributo de sello.
Starlark
El lenguaje de extensión para escribir reglas y macros Un subconjunto restringido de Python (sintáctica y gramaticalmente) destinado al propósito de configuración y un mejor rendimiento. Usa la extensión del archivo .bzl. Los archivos BUILD usan una versión aún más restringida de Starlark (por ejemplo, no usar definiciones de la función def), antes conocida como Skylark.
Consulta también: documentación sobre lenguaje de Starlark
Marcas de inicio
Es el conjunto de marcas especificadas entre bazel y el comando, por ejemplo, la compilación --host_jvm_debug de bazel. Estas marcas modifican la
configuración del servidor de Bazel, por lo que cualquier modificación de
las marcas de inicio hace que se reinicie el servidor. Las marcas de inicio no son específicas de ningún comando.
Objetivo
Es un objeto que se define en un archivo BUILD y que se identifica con una etiqueta. Los destinos representan las unidades que se pueden compilar de un lugar de trabajo desde la perspectiva del usuario final.
Un objetivo que se declara mediante la creación de una instancia de una regla se denomina objetivo de la regla. Según la regla, estos pueden ejecutarse (como cc_binary) o probarse (como cc_test). Los objetivos de la regla suelen depender de otros objetivos a través de sus atributos (como deps). Estas dependencias forman la base del gráfico de destino.
Además de los objetivos de las reglas, también existen los objetivos de archivos y los de grupos de paquetes. Los destinos de archivo corresponden a los artefactos a los que se hace referencia en un archivo BUILD. Como un caso especial, el archivo BUILD de cualquier paquete siempre se considera un archivo de origen de destino en ese paquete.
Los objetivos se descubren durante la fase de carga. Durante la fase de análisis, los objetivos se asocian con las configuraciones de compilación para formar objetivos configurados.
Gráfico de destino
Un gráfico en la memoria de objetivos y sus dependencias. Se generan durante la fase de carga y se usan como entrada en la fase de análisis.
Patrón de objetivo
Una manera de especificar un grupo de destinos en la línea de comandos. Los patrones que se usan con mayor frecuencia son :all (todos los objetivos de la regla), :* (todos los objetivos de la regla y el archivo), ... (el paquete actual y todos los subpaquetes de forma recurrente). Se puede usar en combinación. Por ejemplo, //...:* significa todos los destinos de reglas y archivos en todos los paquetes de manera recurrente desde la raíz del lugar de trabajo.
Pruebas
Los destinos de las reglas crearon instancias de las reglas de prueba y, por lo tanto, contienen un ejecutable de prueba. Un código de retorno de cero luego de la finalización del ejecutable indica que la prueba se completó correctamente. El contrato exacto entre Bazel y las pruebas (como las variables de entorno de prueba y los métodos de recopilación de resultados de pruebas) se especifica en la enciclopedia de pruebas.
Cadena de herramientas
Un conjunto de herramientas para generar resultados para un lenguaje. Por lo general, una cadena de herramientas incluye compiladores, vinculadores, intérpretes o linters. Una cadena de herramientas también puede variar según la plataforma, es decir, los componentes de la cadena de herramientas de un compilador Unix pueden diferir para la variante de Windows, aunque la cadena de herramientas sea para el mismo lenguaje. Seleccionar la cadena de herramientas correcta para la plataforma se conoce como resolución de la cadena de herramientas.
Objetivo de nivel superior
Un destino de compilación es de nivel superior si se solicita en la línea de comandos de
Bazel. Por ejemplo, si //:foo depende de //:bar y se llama a bazel build //:foo, para esta compilación, //:foo es de nivel superior y //:bar no de nivel superior, aunque se deberán compilar ambos destinos. Una diferencia importante
entre los objetivos de nivel superior y los que no son de nivel superior es que las marcas
de comandos establecidas en la línea de comandos de Bazel (o mediante
.bazelrc) establecerán la configuración de los objetivos de
nivel superior, pero se podrían modificar con una transición para los objetivos
que no son de
nivel superior.
Condición
Es una asignación del estado de la configuración de un valor a otro. Permite que los destinos en el gráfico de compilación tengan configuraciones diferentes, incluso si se crearon instancias de la misma regla. Un uso común de las transiciones es con las transiciones divididas, en las que ciertas partes del gráfico de destino se bifurcan con configuraciones distintas para cada bifurcación. Por ejemplo, se puede compilar un APK de Android con objetos binarios nativos compilados para ARM y x86 usando transiciones divididas en una sola compilación.
Consulta también: Transiciones definidas por el usuario
Artefacto de árbol
Un artefacto que representa una colección de archivos. Dado que estos archivos no son artefactos en sí mismos, una acción que opere en ellos debe registrar el artefacto de árbol como su entrada o salida.
Visibilidad
Uno de los dos mecanismos que evitan dependencias no deseadas en el sistema de compilación: la visibilidad del objetivo para controlar si otros destinos pueden depender de un objetivo y la visibilidad de la carga para controlar si un archivo BUILD o .bzl puede cargar un archivo .bzl determinado. Sin contexto, por lo general, "visibilidad" se refiere a la visibilidad del objetivo.
Consulta también: Documentación sobre visibilidad
Espacio de trabajo
Un directorio que contiene un archivo WORKSPACE y código fuente para el software que deseas compilar. Las etiquetas que comienzan con // están relacionadas con el directorio del lugar de trabajo.
Archivo WORKSPACE
Define que un directorio sea un lugar de trabajo. El archivo puede estar vacío, aunque suele contener declaraciones de repositorios externos para recuperar dependencias adicionales de la red o del sistema de archivos local.