| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| por Anonimo Cobarde em 18-06-01 21:45 GMT (#1)
|
| Alguem sabe se já traz suporte para os precompiled headers? É de lembrar que estas feature já existe noutros compiladores desde o tempo do DOS, e isto já foi há muito tempo.
Ter que desenvolver um projecto com centenas de ficheiros e quando, por vezes, se modifica um deles, obriga a uma recompilação demorada, isto faz-mos perder muito tempo util que poderia ser gasto no desenvolvimento.
|
| |
| |
| | Alguem percebe o que e que este jovem quer dizer com isto? Sera que se refere ao que se faz com as Makefiles?
|
| |
| | Hum ... precompiled headers... não é essa coisa que tornas os projectos feitos em VC++ 6 inuteis , demorados e cheios de bugs , pq simplesmente o VC++ lixa akilo tudo com a brincadeira dos precompiled headers ...
|
| |
| | Se souberes organizar as depêndencias convenientemente e estruturares bem o projecto, apenas seráo recompilados os ficheiros afectados pela alteração.
|
| |
| | | Nao, nao traz suporte para precompiled headers. E para quem nao sabe para que serve:
No modelo de compilacao utilizado pelo gcc, ao compilar um ficheiro.c, o gcc recompila sempre a informacao contida no ficheiros #incluidos. Na verdade, o gcc nem distingue a o conteudo dos ficheiros incluidos dos do proprio ficheiro.c, uma vez que o que ele compila e' a saida do cpp, que e' responsavel por preprocessar todas as directivas de compilacao #qqcoisa.
Ao analizar a hierarquia de #includes num dado programa, e' mais do que obvio que ha' aqui muito desperdicio de tempo, que pode ser eliminado.
Precompiled headers e' algo que ja' existe noutros compiladores a' muito tempo, antes ate' do Visual C.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | A todos aqueles que se lembram da RedHat 7.0:
Esta nova versão do gcc vem com 60 dos 66 patches feitos pela RedHat... ou seja é numa boa parte desenvolvido pela redhat... Aquele tal que diziam que era uma bosta que vinha na Red Hat e que nao compilava nada, porque havia nao sei quantos programadores que exploravam uns bugs do compilador que quase parecia o IE, quando nao sabia inventava codigo, e mal a redhat resolveu isso, foi o que foi... Esses mesmos agora que vejam o changelog e que contem os patches da redhat :)...
Finalmente para um individuo que aí anda a dizer que a Mandrake tem muito a aprender com a Red Hat... que conte os patch´s da Mandrake no gcc ;)...
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| |
| |
| | A signitificativa contribuição que a Red Hat tenha tido no desenvolvimento do GCC a meu ver não justifica a utilização de uma distribuição supostamente estável para cobaia de GCC. É lógico que o desenvolvimento de novas funcionalidades obriga a uma fase de instabilidade do software, no entanto existem timings e ambientes para se realizar esta fase que não propriamente ambiente final de "produção" (se é que podemos atribuir tal a uma distribuição Linux).
|
| |
| | Cobaia ?? Desenvolvimento ?? Não jovem, o que nao compilava, nao compilava porque exitia código que aproveitava meia duzia de falhas do egcs QUE FORAM CORRIGIDAS nessa versao, assim como os mesmo patch´s fazem parte desta versao... Repara que sao coisas diferentes!... ;) Nao foi o compilador que veio por em causa a instabilidade da distro, mas sim a utilizaçao de codigo duvidoso, afinal a redhat compilou a distro inteira com aquele compilador ;)=
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| |
| | "nao compilava porque exitia código que aproveitava meia duzia de falhas do egcs"
Oh jovem explica lá essa de código que aproveita falhas de um compilador. Como programador o máximo que já tentei utilizar das especificidades de um compilador foi factores de optimização.
|
| |
| | Há mil e uma maneiras de fazer código furado que não compila. É claro que quando um programa não funciona a culpa é sempre do compilador.
O melhor (mau) exemplo de código que rebentava com o gcc e que provava que o gcc da redhat não funcionava era o xracer em que numa única função eram feitas várias centenas (!!!) de chamadas de funções (o que estourava com o algoritmo de optimização da compilação que é de complexidade O(N^2) em ocupação de memória). Programadores assim deviam voltar para a primária. Mas há código mais simples (e errado) que rebenta com compiladores, algum desse código aparece de vez em quando no kernel do Linux e nem os próprios autores têm problemas em admitir que a culpa é deles.
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| |
| | "Finalmente para um individuo que aí anda a dizer que a Mandrake tem muito a aprender com a Red Hat... que conte os patch´s da Mandrake no gcc ;)...
Ui ui, agora o factor de qualidade duma distribuição Linux é a quantidade de patch's que esta introduz no GCC.
Ainda bem que a Red Hat se preocupa mais com o GCC e deixa os cuidados com umna distribuição em si para a Mandrake que por sua vez pode muito bem utilizar o GCC onde a RedHat contribuiu :)
|
| |
| | Er... nao era bem isso, era mais um individuo que surgiu ai a dizer que a Red Hat tinha que aprender muito com a Mandrake... acho que nao me fiz perceber... 1000 apologies
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| |
| | Até eu te digo que o critério é um bocado injusto dado que a parte da RH que gera os patches gcc é a Cygnus (ie. egcs) :)
|
| |
| | Bem, por acaso a RH comprou a Cygnus, sendo assim, os patches são da RH.
|
| |
| | | Interessante! A RH manda cá para fora uma distribuição com um compilador mal amanhado preso por arames e tu não achas isso mal!? Eu acho que é de louvar que a RH tenha dado um grande contributo para o GCC, é um contributo muito importante! Mas não creio que seja boa política lançar distribuições que se querem de qualidade com software semi-funcional. Deve-se disponibilizar para quem quiser a semi-funcionalidade, isso está bem.
Airegin |
| |
| | A RH manda cá para fora uma distribuição com um compilador mal amanhado preso por arames e tu não achas isso mal!?
A RH foi pioneira no ponto de vista que mandou ca' para fora uma distribuição com um compilador mais evoluido. A prova que esse compilador era mais evoluido, e' que este GCC 3.0 esta' muito mais proximo do GCC que vinha com a RH que qualquer outro GCC de outra distro.
O problema com o GCC da RH foi que certos programadores tiravam partida de coisas que nao deveriam tirar. A forma como o GCC manipulava estruturas, etc. Mas a maior critica foi que os binarios gerados eram incompativeis com a outras distros. O pessoal do GCC nunca consegui definir uma ABI decente, por isso o que se pode dizer e' que os binarios eram diferentes, nao incopativeis porque o que existia nao era uma standard.
Mas deixa para la', o mesmo aconteceu quando a RH lançou a glibc. Julgo que se a RH não tivesse feito isso ainda estavamos hoje com a libc5.
Eu fico contente com uma distro faz uma coisa dessas, especialmente se for uma distro de peso, como e' o caso da RH, porque faz com que mais pessoas usem essas novas coisas e se corrijam alguns bugs que existam muito mais depressa. Evolução!
|
| |
| | | A woody (Debian 2.3) tem o gcc-3.0pre há já bastante tempo. Mas não é o default. Pode-se ter o 2.95 e simultaneamente o 3.0 para ir experimentando (e quem quiser pode apagar o 2.95 à sua conta e risco). Será que ter coisas que não funcionam (independentemente de quem é a culpa) dará uma boa imagem à distro (e ao Linux, quando a distro tem o peso que tem no mundo Linux)?
|
| |
| | A Debian e' um mau exemplo. Nesta mensagem podes ver que a Debian tambem o fez em tempos.
Será que ter coisas que não funcionam (independentemente de quem é a culpa) dará uma boa imagem à distro (e ao Linux, quando a distro tem o peso que tem no mundo Linux)?
Nao funcionam? Desculpa mas essa afirmação está errada. Funciona tão bem que a RH compilou uma distro inteira com esse gcc. O source do kernel tinha alguns problemas, que logo foram corrigidos, mas para garantir que funcionava a RH meteu tambem o kgcc para garantir a compatibilidade com "broken code" (palavras do Alan Cox). Não sei onde vais buscar a ideia de "não funciona".
|
| |
| | ter coisas que não funcionam
O compilador tinha coisas que não funcionavam sim, o funcionar para a distro toda não invalida a afirmação. Até mesmo as versões instáveis ou de desenvolvimento funcionam :)
|
| |
| | Claro que deves ser capaz de dar exemplos disso que afirmas. Diz la um exemplo de algo que o GCC da RH tinha mal e que funcionava bem no anterior e nos das outras distros, e que o problema fosse do GCC da RH.
|
| |
| | O compilador que vinha com o RH7.0 tinha alguns bugs que foram corrigidos nos updates pouco tempo depois, correcção essa que permitia ao 2.96 compilar o kernel 2.4 sem problemas.
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| |
| | | Na Debian, em tempos, havia o gcc 2.7.x para compilar o kernel (se nao estou em erro, era o compilador default) e havia o egcs, tal como hoje temos na woody o 2.95.x e o 3.0pre. Por isso, a Debian fez em tempos o que continua a fazer ainda hoje. Mas na instalação dos pacotes era/é tornado bem claro com qual dos compiladores se devia compilar o kernel (isso era escrito explicitamente na descricao do pacote) e com qual não se o devia tentar compilar (para além do aspecto importante de qual é o compilador por default, que, no entanto, pode sempre ser alterado pelo utilizador). Não sei se isto foi o que o pessoal da RH fez também (não trabalho com essa distro há já algum tempo) mas pareceu-me que alguma gente foi apanhada de surpresa com um compilador que não compilava o kernel, não sei se por azelhice própria se por falta de informação da parte da RH.
|
| |
| | Se nao estou em erro, o gcc 2.65.0 passou a chamar-se de egcs, nao estou certo da versao porque ja foi a algum tempo!...
compilador que não compilava o kernel, não sei se por azelhice própria se por falta de informação da parte da RH
Sim, claro a Red Hat resolve uns bugs que invalidam a compilaçao de algum codigo MAL FEITO e que EXPLORA BUGS DO GCC,e a Red Hat é que fez bosta... É só pseudo coders aqui... Escrevem codigo de m3rda e depois a culpa é do compiler que ao serem resolvidos alguns bugs... deixa de compilar CODIGO MAL FEITO... Sim, culpa a Red Hat, culpa lá quem quiseres!
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| |
| | E se não estou em erro o próprio egcs não era visto com bons olhos pelo comité do gcc, foi lançado porque o pessoal estava farto de esperar por avanços no gcc que tardavam em chegar, mas a pressão acabou por provocar o lançamento de novos gccs. Eles nunca devem ter ouvido falar de aumentos incrementais de funcionalidade. Se continuassem com a atitude que tinham por volta do 2.7.x só teriamos uma nova versão lá para o ano 3545!
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| |
| | | Os tipos do pgcc e outros projectos derivados do gcc, que nao viam os seus patchs incluidos no gcc devido a uma filosofia mto fechada, decidiram juntar-se e formar o egcs. Depois o proprio comite' gcc viu que o do egcs estava a fazer um bom trabalhou e decidiu que seria o egcs a tratar de todo o gcc por ai em diante...
hugs
Strange |
| |
| | | Sim, culpa a Red Hat, culpa lá quem quiseres! Não se trata de culpar a RH (mas entende o que eu digo como quiseres também ;-) ) muito menos por corrigir bugs em software importante. Trata-se de lamentar a confusão que se gerou em torno disso, que talvez pudesse ser evitada, independentemente de quem seria a culpa (ver o meu primeiro comentário: #16). Em resumo, repetindo tudo outra vez, mas de uma outra maneira: ainda bem que a RH contribuiu para a melhoria do gcc com as suas correccoes de bugs. No entanto, como algum codigo (por sinal, importante) explorava esses bugs (de uma forma certamente questionavel) talvez não fosse despropositado ter-se tornado bem claro e fácil como compilar esse código (com o compilador antigo, c/ os respectivos bugs). Nota que estou a falar genericamente sobre qual deveria ser o comportamente de uma empresa líder na produção de distribuições de Linux (e uma distribuição é uma colecção de programas que funcionam uns com os outros!). É possível que este caso tenha sido um pouco empolado e a sua real importância tenha sido bastante menor do que nos pareceu pelas notícias que andamos por aí a ler. Estou a fazer esta ressalva porque, como não uso RH há bastante tempo, não pude avaliar a importância do "caso".
|
| |
| | > Mas a maior critica foi que os binarios gerados eram incompativeis com a outras distros. O pessoal do GCC nunca consegui definir uma ABI decente, por isso o que se pode dizer e' que os binarios eram diferentes, nao incopativeis porque o que existia nao era uma standard.
Nota: isto é válido para C++, não C. Os últimos 6 meses teem sido uma trapalhada para o g++.
|
| |
| | >A RH manda cá para fora uma distribuição com um compilador mal amanhado preso por arames e tu não achas isso mal!?
Compilador esse que acabou por se transformar mais coisa menos coisa no gcc3. Pelo sim pelo não acho melhor continuares com o gcc2.7.2.3 até ver!
|
| |
| | "dos 66 patches da redhat que la estavam, 60 estao no GCC 3.0" AHHHHHHHHHHHH OK!!!! fiquei a saber que uma versão 3.0 ( zero) já tem 66 (!!) patches !!!
|
| |
| | Dos 66 patches ao CVS! DUH!
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| |
| | Eu tentei compilar ontem a noite no mandrake 8.0 e falhou na segunda etapa (primeiro com CC=gcc e depois com CC=kgcc).
Ainda nao tive disponibilidade para saber o q de facto se passa. Logo mais vou procurar possiveis causas.
--- |
| |
| | Pelo menos a compilar o kernel tens de especificar como compilador o kgcc, usando o comando
CC=kgcc make
o kgcc e uma versao antiga do egcs que e mais segura de usar q os gcc da redhat (e mandrake). O kgcc vem nos cds da distribuicao e pode ser necessario instala-lo manualmente.
Estou a correr o kernel 2.4.5 compilado com o kgcc sem qualquer problema (tirando o conflito entre o modulo nvidia e o xdm *suspiro*).
Por uma questao de coerencia e seguranca, uso sempre o kgcc para compilar tudo, com a excepcao dos meus programas (onde sou capaz de resolver conflitos facilmente).
Se o programa tiver um 'configure' para compilar, verifica se o 'configure' nao aceita um argumento para especificar o compilador de C (configure --help).
Quanto ao gcc 3.0, compilaste-o todo ou so alguns modulos?
--- |
| |
