2010-07-16 14 views
7

Acabo de enterarme recientemente de que puede configurar Visual Studio (pero esta pregunta es la misma para cualquier compilador) para volcar los archivos .o intermedios en una carpeta separada fuera del árbol fuente, en lugar de junto a cada proyecto individual. Eso hace que sea más fácil limpiar el proyecto para archivar en zip o algo así.¿Por qué las construcciones "fuera de origen" no son las predeterminadas?

¿Por qué ese tipo de configuración no es más común? ¿Hay algún inconveniente significativo?

+2

no estoy seguro de por qué no es el valor por defecto, pero tienes razón , debería ser. Escribir una hoja de propiedades para fi x este es probablemente el mejor cambio que he hecho en mi flujo de trabajo VS. – jalf

Respuesta

2

Este es el predeterminado en Visual Studio, y lo ha sido durante bastante tiempo (al menos desde VC++ 6). El directorio intermedio se establece de manera predeterminada en el mismo directorio de salida, no en el directorio de origen. Esto significa que todos los archivos de objeto se colocan junto al resultado final.

De hecho, requiere un poco de pánico si está trabajando con proyectos que esperan que la salida del compilador se coloque junto a los archivos fuente. Como VC++ tiene por defecto dar a los archivos de objeto el mismo nombre que su archivo fuente correspondiente (pero con una extensión diferente), si tiene varios archivos fuente con el mismo nombre (pero diferentes rutas), la compilación de cada archivo fuente sobrescribirá el objeto correspondiente archivo. El último archivo que se compilará "gana".

Esto, naturalmente, rompe la construcción.

Requerir que los nombres de los archivos fuente sean globalmente únicos en un proyecto es realmente bastante molesto. Puede modificar la ubicación de salida para que, por ejemplo, incluya una ruta; el enlazador todavía hace lo correcto.

+0

¿Eh? De forma predeterminada, crea una subcarpeta Debug/Release debajo de la carpeta del proyecto, que contiene todos los archivos intermedios. Ciertamente no coloca "todos los archivos de objeto junto al resultado final". No es lo que llamaría "fuera de fuente". – jalf

+0

Sí, pero tampoco los coloca junto a los archivos fuente, sino en un subdirectorio. –

+0

Resuelve el escenario de "últimos triunfos compilados" haciendo un '$ (SolutionDir) \ Build \ $ (ProjectName) \ $ (PlatformToolset) \ $ (Platform) \ $ (Configuration)' para 'IntDir'. –

1

Probablemente esta sea una pregunta con una respuesta histórica. Los primeros compiladores de C (y por lo tanto los primeros compiladores de C++) se escribieron en y para Unix. No hay un lugar "estándar" para mucho de todo en Unix, con solo algunas excepciones. Como tal, la práctica habitual es simplemente poner todo en el directorio de trabajo actual, a menos que se indique lo contrario.

+3

Visual Studio no genera los archivos de objeto en el directorio de trabajo actual, pero los tira en carpetas generadas en cada proyecto; la pregunta es por qué no solo los agrupa por solución. Además, Microsoft no es muy conocido por hacer las cosas de cierta manera porque históricamente lo han hecho otros –

+0

Agruparlos por solución realmente haría que el problema descrito en la pregunta (de conflictos de nombre) sea mucho peor. Es cierto que nunca he visto nombres de archivos que chocan en un solo proyecto (en serio, ¿por qué?), Pero en todos los proyectos, posiblemente mantenidos por diferentes personas, en una única solución, eso es perfectamente posible. –

+0

@Pavel: ¿Por qué empeoraría el problema?Coloque los archivos obj en '$ (SolutionDir) \ obj \ $ (ProjectName)' o algo por el estilo, y no entrarán en conflicto en los proyectos, mientras se encuentren fuera del árbol de fuentes. (también, ¿dónde preguntó el OP sobre los conflictos de nombres?) – jalf

0

Si utiliza Qt Creator como su IDE de desarrollo, entonces la versión 2 ahora habilita 'versiones paralelas' de manera predeterminada, que funciona exactamente de la manera que usted describe y es muy útil. También es una casilla de verificación única para activarlo o desactivarlo, lo cual es un poco menos complicado que VS.

1

Voy a ir con "porque VS se desarrolla en el vacío, donde las ideas del mundo exterior no suelen interferir. Organizar archivos de compilación de esta manera funcionó de manera aceptable en las primeras versiones de Visual Studio (o su sin precursores de Studio), y ya que es la forma en que siempre se ha hecho en la empresa, y nadie entró desde el exterior y dijo "ya sabes, el resto del mundo realmente le gustaría separar los archivos intermedios basura y su real código fuente", el equipo VS nunca se imaginó que era un problema.

es sólo una suposición, pero no puedo pensar en una mejor explicación.

Cuestiones relacionadas