Compilação ReactOS

Post Reply
gnome_gtk
Posts: 35
Joined: Sun Dec 09, 2007 10:08 pm

Compilação ReactOS

Post by gnome_gtk »

Fiz a atualização do RosBE para o 1.1 d fui tentar compilar de novo. Tinha mais de 2.5Gb de espaço livre em disco e nem assim teve espaço o bastante para a compilação. Isso levando em conta que o arquivo final tem menos de 100Mb. Não tem muito lixo sendo compilado não?
Last edited by gnome_gtk on Wed Jan 23, 2008 1:09 pm, edited 1 time in total.
Jeronimus Linuxius
Posts: 43
Joined: Mon Jun 18, 2007 11:14 pm

Re: Compilação ReactOS

Post by Jeronimus Linuxius »

gnome_gtk wrote:Fiz a atualização do RosBE para o 1.1 d fui tentar compilar de novo. Tinha mais de 2.5Gb de espaço livre em disco e nem assim teve espaço o bastante para a compilação. Isso levando em conta que o arquivo final tem menos de 100Mb. Não tem muito lixo sendo compilada não?
Não. É natural a compilação ocupar muito espaço...

JJ
gnome_gtk
Posts: 35
Joined: Sun Dec 09, 2007 10:08 pm

Post by gnome_gtk »

Gerar mais de 25x mais dados do que o próprio software final.
Mesmo levando em conta que gera os arquivos objeto, executáveis e ISO final, ou seja, que a mesma compilação gera os dados em 3x ainda daria mais de 8x mais arquivos gerados durante a compilação do que as saídas.
Jeronimus Linuxius
Posts: 43
Joined: Mon Jun 18, 2007 11:14 pm

Post by Jeronimus Linuxius »

gnome_gtk wrote:Gerar mais de 25x mais dados do que o próprio software final.
Mesmo levando em conta que gera os arquivos objeto, executáveis e ISO final, ou seja, que a mesma compilação gera os dados em 3x ainda daria mais de 8x mais arquivos gerados durante a compilação do que as saídas.
Não quiz dizer que é aceitável que toda a tralha extra faça a build tree ocupar 25 vezes o tamanho que ocupa a versão final. Só disse que, no ReactOS, é habitual.

De qualquer das maneiras, os ficheiros objecto fazem toda a árvore ocupar muito mais espaço. Levando em consideração que muitos executáveis têm origem numa grande quantidade de ficheiros objecto, e que os nomes das funções (tanto da API como internos aos programas), seguindo a ExSantaModaDoWindowsNT, são looooongos como o camâââââââââââââââââââândro, não é difícil imaginar uma tal estatística!
Além disso, penso que o build system stripa os executáveis quando estão prontos (o que os faz ocupar um bocado de menos espaço)...

Não há nada que possa fazer contra isso...

JJ
gnome_gtk
Posts: 35
Joined: Sun Dec 09, 2007 10:08 pm

Post by gnome_gtk »

Vamos por partes:

- Nomes de arquivos e funções não são os grandes vilões do tamanho do arquivo compilado nem creio que seja a quantidade de arquivos objetos. O que acho é deve ter muita coisa sendo compilada mais de uma vez ou mesmo código que faça parte do ReactOS mas não esteja sendo utilizado.
- É provável que os 3Gb que a compilação do ReactOS estão consumindo não te façam falta mas lembre que o mesmo ainda está bem menor do que a futura versão final. Imaginando um futuro ReactOS 1.0 de 250-500Mb, caso sigamos a mesma proporção consumirá a maior arte de um HD médio para compilar. Se não houver jeito, beleza mas acho que não custaria dar uma boa olhada para ver o porquê disso.
Jeronimus Linuxius
Posts: 43
Joined: Mon Jun 18, 2007 11:14 pm

Post by Jeronimus Linuxius »

gnome_gtk wrote:Vamos por partes:

- Nomes de arquivos
Nomes de ficheiros não. Os nomes de ficheiro são guardados como metadados, pelo que não têm influência nenhuma (no caso de alguns sistemas de ficheiros), ou particamente nenhuma (no caso de outros) na quantidade de espaço disponível em disco...
e funções não são os grandes vilões do tamanho do arquivo compilado nem creio que seja a quantidade de arquivos objetos.
Mas a mistura dos dois factores pode ser. Não te esqueças que um objecto não linkado significa uma série de informações para além do código do mesmo, a maioria das quais nomes de símblos (que no windows costumam ser enormes)... E que num programa pode haver cerca de 30% dos ficheiros objecto a chamar a API ("estatística" completamente infundada), o que multiplica o espaço ocupado pelos nomes dos símbolos por n...

Para além disso, acho que os objectos são compilados com a opção "-g" (informação simbólica extra para o depurador), o que acentua ainda mais o tamanho da soma dos objectos face ao da versão completamente linkada...

É claro que eu posso estar completamente enganado e a razão não ter nada a ver com isto...
O que acho é deve ter muita coisa sendo compilada mais de uma vez ou mesmo código que faça parte do ReactOS mas não esteja sendo utilizado.
É possível. Sei que ambas as versões do FreeLoader (a standalone e a do CD de instalação) são sempre compiladas, quer se venha a necessitar de uma ou da outra... Mas o FreeLoader é só um programa...
- É provável que os 3Gb que a compilação do ReactOS estão consumindo não te façam falta mas lembre que o mesmo ainda está bem menor do que a futura versão final.
Isso é bem verdade. No entanto, também é verdade que o ReactOS é desenvolvido como um sistema operativo mais-que-completo (muito mais do que o Linux ou o FreeBSD), e que (acho) que o espaço que a compilação ocupa actualmente não é muito diferente do espaço que a compilação, por exemplo, do OpenOffice.org ocupa (e o OO.org é só um programa, embora muito complexo)...
Imaginando um futuro ReactOS 1.0 de 250-500Mb, caso sigamos a mesma proporção consumirá a maior parte de um HD médio para compilar. Se não houver jeito, beleza mas acho que não custaria dar uma boa olhada para ver o porquê disso.
Podes sempre reportar bug... É sempre bom que o software ocupe menos espaço...
Além disso, vai ao directório onde estão os objectos de um programa com muitos ficheiros e vê quando espaço eles ocupam. Depois vê quanto espaço ocupa o .exe respectivo e tira as tuas conclusões...

Compilo o ReactOS há já uns três anos. Infelizmente, não escrevi o tempo que tem demorado ao longo das versões...

JJ
Jeronimus Linuxius
Posts: 43
Joined: Mon Jun 18, 2007 11:14 pm

Post by Jeronimus Linuxius »

Jeronimus Linuxius wrote:Além disso, vai ao directório onde estão os objectos de um programa com muitos ficheiros e vê quando espaço eles ocupam. Depois vê quanto espaço ocupa o .exe respectivo e tira as tuas conclusões...
Afinal tinha aqui uma árvore completamente compilada...

Por exemplo, o executável do kernel (ntoskrnl.exe) ocupa apenas 2,4 MB. No entanto, só os ficheiros objecto do módulo "ke" (que é só parte do kernel) ocupam 16,1 MB. Os ficheiros objecto do kernel ocupam, ao todo, 119.7MB.

Abrindo um dos objectos com um editor hexadecimal, vejo carradas de código C...
Indicativo de que foi usada a opção -g na compilação do ficheiro fonte.
A tabela de símbolos acupa 2KB, ou nem tanto, no final do ficheiro.

Em makefile.auto:

Code: Select all

ntoskrnl_CFLAGS += $(PROJECT_CFLAGS) -g -pipe -Werror -nostdinc -fno-optimize-sibling-calls
JJ
Post Reply

Who is online

Users browsing this forum: No registered users and 8 guests