Tuosta ei tajua mitään. Ei edes ymmärrä mihin kääntäminen tyssää.
Miksi ei normaalit make-tiedostot kelpaa kuten muillekin?
Miksi Chromium OS pitää tehdä jollain Portagella? Miksi ei käytetä jotain normaalia helppoa tapaa?
Anonyymi
12
428
Vastaukset
- Anonyymi
"Miksi ei normaalit make-tiedostot kelpaa kuten muillekin?"
saman kysymyksen voisi esittää OpenSSL:n tekijöille !
Miksi ei ole makefileä, vaan monimutkainen perl -skripti...
ja mikä pahinta:
vain 64 -bittinen versio on ilmainen, 32-bittisestä versiosta pitää maksaa !
Miksi?
Kun suositellaan ActivePerliä, ja siitä 32 -bittisen version saa vain maksamalla!
Kilpailijasta Strawberry Perlistä saisi sekä 32- että 64 -bittiset versiot maksutta, mutta sehän ei taas OpenSSL:n tekijöille kelpaa, kuten ei siis makefilekään.
Ilmeisesti OpenSSL:ää ei ole koodattu C:llä, vaan jollain käsittämättömällä pseudokielellä, jonka Perl -skripti muuntaa C-kielelle ja syöttää muunnoksen lopputuloksen C -kääntäjälle.
Miksi? - no en minä vaan tiedä! Kai siksi, että kaikki pitää tehdä mahdollisimman vaikealla, hankalalla ja sekavalla tavalla !- Anonyymi
"vain 64 -bittinen versio on ilmainen, 32-bittisestä versiosta pitää maksaa !"
Ei siitä mitään tarvitse maksaa. Olen käyttänyt OpenSSL:ää aikoinaan 32-bittisenä maksamatta.
"Kun suositellaan ActivePerliä, ja siitä 32 -bittisen version saa vain maksamalla!"
ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty.
"Ilmeisesti OpenSSL:ää ei ole koodattu C:llä, vaan jollain käsittämättömällä pseudokielellä, jonka Perl -skripti muuntaa C-kielelle ja syöttää muunnoksen lopputuloksen C -kääntäjälle."
Vilkaisin lähdekoodeja. Ihan normaalilta C:ltä näytti mutta siellä on myös perlillä kirjoitettuja osia.
Siinähän ei ole mitään tavatonta, että ohjelmien teossa on käytetty useita kieliä. - Anonyymi
Anonyymi kirjoitti:
"vain 64 -bittinen versio on ilmainen, 32-bittisestä versiosta pitää maksaa !"
Ei siitä mitään tarvitse maksaa. Olen käyttänyt OpenSSL:ää aikoinaan 32-bittisenä maksamatta.
"Kun suositellaan ActivePerliä, ja siitä 32 -bittisen version saa vain maksamalla!"
ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty.
"Ilmeisesti OpenSSL:ää ei ole koodattu C:llä, vaan jollain käsittämättömällä pseudokielellä, jonka Perl -skripti muuntaa C-kielelle ja syöttää muunnoksen lopputuloksen C -kääntäjälle."
Vilkaisin lähdekoodeja. Ihan normaalilta C:ltä näytti mutta siellä on myös perlillä kirjoitettuja osia.
Siinähän ei ole mitään tavatonta, että ohjelmien teossa on käytetty useita kieliä."ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty."
Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä".
Kas kun Windowsissa ei ole PERLiä, ellei sitä siihen itse asenna.
JA tosiaan OpenSSL:n tekijät kehottavat käyttämään Activestate Perliä, ja siitä 64-bittinen versio on ilmainen, mutta 32 -bittisestä versiosta pitää maksaa, ei sitä ilmaiseksi saa.
Strawberry Perlistä saa ilmeisesti molemmat sekä 32- että 64 -bittiset versiot ilmaiseksi, mutta ilmeisesti OpenSSL:n Perl -pohjainen kääntämisjärjestelmä on tehty niin, ettei se toimi Strawberry Perlillä kunnolla / ollenkaan.
Joskus yritin, mutta sen jäljiltä .c -tiedostoissa on syntaktisesti kelvotonta C -kieltä muistuttavaa kieltä, joka ei kuitenkaan C -kääntäjälle kelpaa, vaan C -kääntäjä antaa kasan virheilmoituksia (mingw -gcc 32-bit versio).
Ilmeisesti OpenSSL varsinainen lähdekoodi on joko C -kieltä tai jotain sellaista kieltä, jonka tuo Perl -skriptin olisi tarkoitus muokata C -kääntäjälle kelpaavaan muotoon, mutta windowsissa 32-bit Strawberry Perliä käyttämällä lopputulos on se, ettei mingw-gcc hyväksy kääntöjärjestelmän sille syöttämää C -kieltä (tai jotakin C -kieltä muistuttavaa kieltä, jota kääntäjä ei kuitenkaan kelpuuta).
Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia.
Miksei voida tehdä näin:
kaanna.bat:
gcc -c moduli1.c
gcc -c moduli2.c
gcc -c moduli3.c
gcc -c moduli4.c
gcc -c paaohjelma.c
gcc -c libkirjasto.c
gcc moduli1.o moduli2.o moduli3.o moduli4.o paaohjelma.o -o ohjelma.exe
gcc -static -shared moduli1.o moduli2.o moduli3.o moduli4.o libkirjasto.o -o libkirjasto.dll
viimeisellä rivillä tuo -static on siksi, että silloin riittää, kun tuon DLL:n kopioi kohdekoneelle, eikä kohdekoneella tarvita muuta kuin se ohjelma, joka tuota libkirjasto.dll haluaa käyttää sekä se, minkä Microsoftin windowsin asennusohjelma tyhjälle koneelle asentaa, ei MITÄÄN muuta !
Ilman tuota -static -valitsinta ohjelmaa ei saa käyntiin, kun valittaa tuon libkirjasto.dll:n tarvitsemista lukuisista muista DLL:stä, joita ei kohdekoneella ole.
Tuollainen "kääntöjärjestelmä" olisi se paras.
Joo, perus windowsin cmd.exe ei toki ole paras tuollaisen BAT -tiedoston sellaisenaan ajamiseen, mutta perusperiaate on siinä selkein mahdollinen.
voisihan siellä olla:
kaanna_dummy.BAT
ja
kaanna_smart.BAT
joista tuo jälkimmäinen olisi muuten sama, mutta jokaisen gcc -komentorivin jälkeen olisi:
if ERRORLEVEL 2 goto VIRHE
ja jossain tuossa BAT -tiedostossa:
:VIRHE
echo Tapahtui käännösvirhe. Kääntämisketju lopetettu.
goto LOPPU
:LOPPU
rem viimeinen BAT -tiedoston rivi.
eli jotain tuon tapaista, eli muuten sama kuin aiempi, mutta jos gcc palauttaa virhekoodin, kääntäminen ja linkkaaminen seuraavien vaiheiden osalta lopetetaan. - Anonyymi
Anonyymi kirjoitti:
"ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty."
Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä".
Kas kun Windowsissa ei ole PERLiä, ellei sitä siihen itse asenna.
JA tosiaan OpenSSL:n tekijät kehottavat käyttämään Activestate Perliä, ja siitä 64-bittinen versio on ilmainen, mutta 32 -bittisestä versiosta pitää maksaa, ei sitä ilmaiseksi saa.
Strawberry Perlistä saa ilmeisesti molemmat sekä 32- että 64 -bittiset versiot ilmaiseksi, mutta ilmeisesti OpenSSL:n Perl -pohjainen kääntämisjärjestelmä on tehty niin, ettei se toimi Strawberry Perlillä kunnolla / ollenkaan.
Joskus yritin, mutta sen jäljiltä .c -tiedostoissa on syntaktisesti kelvotonta C -kieltä muistuttavaa kieltä, joka ei kuitenkaan C -kääntäjälle kelpaa, vaan C -kääntäjä antaa kasan virheilmoituksia (mingw -gcc 32-bit versio).
Ilmeisesti OpenSSL varsinainen lähdekoodi on joko C -kieltä tai jotain sellaista kieltä, jonka tuo Perl -skriptin olisi tarkoitus muokata C -kääntäjälle kelpaavaan muotoon, mutta windowsissa 32-bit Strawberry Perliä käyttämällä lopputulos on se, ettei mingw-gcc hyväksy kääntöjärjestelmän sille syöttämää C -kieltä (tai jotakin C -kieltä muistuttavaa kieltä, jota kääntäjä ei kuitenkaan kelpuuta).
Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia.
Miksei voida tehdä näin:
kaanna.bat:
gcc -c moduli1.c
gcc -c moduli2.c
gcc -c moduli3.c
gcc -c moduli4.c
gcc -c paaohjelma.c
gcc -c libkirjasto.c
gcc moduli1.o moduli2.o moduli3.o moduli4.o paaohjelma.o -o ohjelma.exe
gcc -static -shared moduli1.o moduli2.o moduli3.o moduli4.o libkirjasto.o -o libkirjasto.dll
viimeisellä rivillä tuo -static on siksi, että silloin riittää, kun tuon DLL:n kopioi kohdekoneelle, eikä kohdekoneella tarvita muuta kuin se ohjelma, joka tuota libkirjasto.dll haluaa käyttää sekä se, minkä Microsoftin windowsin asennusohjelma tyhjälle koneelle asentaa, ei MITÄÄN muuta !
Ilman tuota -static -valitsinta ohjelmaa ei saa käyntiin, kun valittaa tuon libkirjasto.dll:n tarvitsemista lukuisista muista DLL:stä, joita ei kohdekoneella ole.
Tuollainen "kääntöjärjestelmä" olisi se paras.
Joo, perus windowsin cmd.exe ei toki ole paras tuollaisen BAT -tiedoston sellaisenaan ajamiseen, mutta perusperiaate on siinä selkein mahdollinen.
voisihan siellä olla:
kaanna_dummy.BAT
ja
kaanna_smart.BAT
joista tuo jälkimmäinen olisi muuten sama, mutta jokaisen gcc -komentorivin jälkeen olisi:
if ERRORLEVEL 2 goto VIRHE
ja jossain tuossa BAT -tiedostossa:
:VIRHE
echo Tapahtui käännösvirhe. Kääntämisketju lopetettu.
goto LOPPU
:LOPPU
rem viimeinen BAT -tiedoston rivi.
eli jotain tuon tapaista, eli muuten sama kuin aiempi, mutta jos gcc palauttaa virhekoodin, kääntäminen ja linkkaaminen seuraavien vaiheiden osalta lopetetaan."Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä"."
No älä käytä sitten sitä Windowsia.
Ei sitä OpenSSL:ää ole tarkoitettu muuhun kuin käyttöjärjestelmän peruspalikoihin ja Microsoft on ihan itse käännellyt ja integroinut SSL toiminnallisuuden valmiiksi että onnistuu SSL yhteys vaikka Edge selaimella tai .NET Corella. Jos haluaa itse käyttää ja muokata sitä jossain niin valitaan työkalut sen mukaan eikä mitään Windowsia, kun ei sitä Windowsia ole sellaiseen tarkoitettu.
"Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia."
Ei minulla vaan ole mitään ongelmia. Ihan normaalia parsimista mitä tehty tietokoneilla jotain 50 vuotta.
"ja jossain tuossa BAT -tiedostossa:"
Ei tietokoneohjelmia tehdessä käytetä mitään BAT -tiedostoja. Nehän ovat jotain DOS-aikaista kuraa.
POSIX standardi määrittelee shellin miten komentoja laitetaan, eli käytännössä Bourne shell -yhteensopiva komentotulkki pitää olla.
Sen lisäksi unohdat kääntämisestä sen, että kun kehitetään ohjelmaa niin ei nyt helvetissä haluta kääntää miljoonaa riviä koodia kun tekee vaikka pienen muutoksen. Make toimii niin, että se käännetään vain muuttuneet kohdat uudestaan niin kehittäminen on hurjasti nopeampaa. Make on aina tehty toimimaan POSIX -yhteensopivan komentotulkin kanssa, 70-luvulta saakka.
Ongelmasi taitaa olla se, että yrität käyttää Windowsia sellaiseen mihin Windowsia ei ole tarkoitettu. Windows on tarkoitettu sovellusten käyttöliittymiä varten ja siihen on sitä varten työkalut. - Anonyymi
Anonyymi kirjoitti:
"Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä"."
No älä käytä sitten sitä Windowsia.
Ei sitä OpenSSL:ää ole tarkoitettu muuhun kuin käyttöjärjestelmän peruspalikoihin ja Microsoft on ihan itse käännellyt ja integroinut SSL toiminnallisuuden valmiiksi että onnistuu SSL yhteys vaikka Edge selaimella tai .NET Corella. Jos haluaa itse käyttää ja muokata sitä jossain niin valitaan työkalut sen mukaan eikä mitään Windowsia, kun ei sitä Windowsia ole sellaiseen tarkoitettu.
"Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia."
Ei minulla vaan ole mitään ongelmia. Ihan normaalia parsimista mitä tehty tietokoneilla jotain 50 vuotta.
"ja jossain tuossa BAT -tiedostossa:"
Ei tietokoneohjelmia tehdessä käytetä mitään BAT -tiedostoja. Nehän ovat jotain DOS-aikaista kuraa.
POSIX standardi määrittelee shellin miten komentoja laitetaan, eli käytännössä Bourne shell -yhteensopiva komentotulkki pitää olla.
Sen lisäksi unohdat kääntämisestä sen, että kun kehitetään ohjelmaa niin ei nyt helvetissä haluta kääntää miljoonaa riviä koodia kun tekee vaikka pienen muutoksen. Make toimii niin, että se käännetään vain muuttuneet kohdat uudestaan niin kehittäminen on hurjasti nopeampaa. Make on aina tehty toimimaan POSIX -yhteensopivan komentotulkin kanssa, 70-luvulta saakka.
Ongelmasi taitaa olla se, että yrität käyttää Windowsia sellaiseen mihin Windowsia ei ole tarkoitettu. Windows on tarkoitettu sovellusten käyttöliittymiä varten ja siihen on sitä varten työkalut.Ja jos Edge ei riitä SSL yhteyksiä varten on sitä myös se Electron keksitty: https://www.electronjs.org/
- Anonyymi
Anonyymi kirjoitti:
"ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty."
Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä".
Kas kun Windowsissa ei ole PERLiä, ellei sitä siihen itse asenna.
JA tosiaan OpenSSL:n tekijät kehottavat käyttämään Activestate Perliä, ja siitä 64-bittinen versio on ilmainen, mutta 32 -bittisestä versiosta pitää maksaa, ei sitä ilmaiseksi saa.
Strawberry Perlistä saa ilmeisesti molemmat sekä 32- että 64 -bittiset versiot ilmaiseksi, mutta ilmeisesti OpenSSL:n Perl -pohjainen kääntämisjärjestelmä on tehty niin, ettei se toimi Strawberry Perlillä kunnolla / ollenkaan.
Joskus yritin, mutta sen jäljiltä .c -tiedostoissa on syntaktisesti kelvotonta C -kieltä muistuttavaa kieltä, joka ei kuitenkaan C -kääntäjälle kelpaa, vaan C -kääntäjä antaa kasan virheilmoituksia (mingw -gcc 32-bit versio).
Ilmeisesti OpenSSL varsinainen lähdekoodi on joko C -kieltä tai jotain sellaista kieltä, jonka tuo Perl -skriptin olisi tarkoitus muokata C -kääntäjälle kelpaavaan muotoon, mutta windowsissa 32-bit Strawberry Perliä käyttämällä lopputulos on se, ettei mingw-gcc hyväksy kääntöjärjestelmän sille syöttämää C -kieltä (tai jotakin C -kieltä muistuttavaa kieltä, jota kääntäjä ei kuitenkaan kelpuuta).
Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia.
Miksei voida tehdä näin:
kaanna.bat:
gcc -c moduli1.c
gcc -c moduli2.c
gcc -c moduli3.c
gcc -c moduli4.c
gcc -c paaohjelma.c
gcc -c libkirjasto.c
gcc moduli1.o moduli2.o moduli3.o moduli4.o paaohjelma.o -o ohjelma.exe
gcc -static -shared moduli1.o moduli2.o moduli3.o moduli4.o libkirjasto.o -o libkirjasto.dll
viimeisellä rivillä tuo -static on siksi, että silloin riittää, kun tuon DLL:n kopioi kohdekoneelle, eikä kohdekoneella tarvita muuta kuin se ohjelma, joka tuota libkirjasto.dll haluaa käyttää sekä se, minkä Microsoftin windowsin asennusohjelma tyhjälle koneelle asentaa, ei MITÄÄN muuta !
Ilman tuota -static -valitsinta ohjelmaa ei saa käyntiin, kun valittaa tuon libkirjasto.dll:n tarvitsemista lukuisista muista DLL:stä, joita ei kohdekoneella ole.
Tuollainen "kääntöjärjestelmä" olisi se paras.
Joo, perus windowsin cmd.exe ei toki ole paras tuollaisen BAT -tiedoston sellaisenaan ajamiseen, mutta perusperiaate on siinä selkein mahdollinen.
voisihan siellä olla:
kaanna_dummy.BAT
ja
kaanna_smart.BAT
joista tuo jälkimmäinen olisi muuten sama, mutta jokaisen gcc -komentorivin jälkeen olisi:
if ERRORLEVEL 2 goto VIRHE
ja jossain tuossa BAT -tiedostossa:
:VIRHE
echo Tapahtui käännösvirhe. Kääntämisketju lopetettu.
goto LOPPU
:LOPPU
rem viimeinen BAT -tiedoston rivi.
eli jotain tuon tapaista, eli muuten sama kuin aiempi, mutta jos gcc palauttaa virhekoodin, kääntäminen ja linkkaaminen seuraavien vaiheiden osalta lopetetaan.Ongelmasi tuntuu olevan se että et tunnu käsittävän IT-alan standardeja.
Aivan keskeisiä standardit ovat
-merkistöstandardit (UTF-8, Unicode)
-verkkoprotokolla standardit (TCP/IP, SMTP, HTTP jne.)
Sitten kun puhutaan noista komentorivityökaluista, C-kielestä ja palvelimista niin sillä alueella standardointi on se POSIX. POSIX standardoinnista tuli myöhemmin LSB standardointi superset joka standardoi enemmän kirjastoja mutta kun viime vuosikymmenellä käyttöjärjestelmätason virtualisoi jyräsi niin tuli defacto standardiksi Linux, ja sen päällä olevissa virtuaalikoneissa sitten voi varsin vapaasti olla mitä tahansa kunhan ne ovat ulos päin verkkoprotokolla standardien mukaisia.
Virtuaalikoneessa oleva service on siis palvelintason ohjelmakomponentti.
Käyttöliittymäpuolella sitten on HTML, DOM, CSS ja Ecmascript standardit, ja serialisoinnissa sitten on JSON ja XML.
Ohjelmointikielillä on myös standardeja, tärkeimpänä Ecmascript, mutta muuten merkitsevät vähemmän. Standardointi auttaa siinä että on vakautta niissä työkaluissa.
Kun ymmärtää mitä IT-alalla on standardoitu, ymmärtää sen että Windowsissa ajetaan käyttöliittymiä ja se lähdekoodi ensisijaisesti on siinä Edgessä. Voi myös tehdä Electronilla sovelluksen jos se ei syystä tai toisesta riitä, tai sitten voi tehdä natiivisovelluksen. Natiivisovellus ei ihan ole niin yhteensopiva, menee helpommin rikki ja senkin pitäisi sitten käyttää näitä standardeja UTF-8, HTTP, SMTP, JSON, XML jne. muotoja.
Mitä ilmeisimmin yrität tehdä jotain väärin kun yrität kääntää OpenSSL:ää Windowsissa. - Anonyymi
Anonyymi kirjoitti:
"Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä"."
No älä käytä sitten sitä Windowsia.
Ei sitä OpenSSL:ää ole tarkoitettu muuhun kuin käyttöjärjestelmän peruspalikoihin ja Microsoft on ihan itse käännellyt ja integroinut SSL toiminnallisuuden valmiiksi että onnistuu SSL yhteys vaikka Edge selaimella tai .NET Corella. Jos haluaa itse käyttää ja muokata sitä jossain niin valitaan työkalut sen mukaan eikä mitään Windowsia, kun ei sitä Windowsia ole sellaiseen tarkoitettu.
"Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia."
Ei minulla vaan ole mitään ongelmia. Ihan normaalia parsimista mitä tehty tietokoneilla jotain 50 vuotta.
"ja jossain tuossa BAT -tiedostossa:"
Ei tietokoneohjelmia tehdessä käytetä mitään BAT -tiedostoja. Nehän ovat jotain DOS-aikaista kuraa.
POSIX standardi määrittelee shellin miten komentoja laitetaan, eli käytännössä Bourne shell -yhteensopiva komentotulkki pitää olla.
Sen lisäksi unohdat kääntämisestä sen, että kun kehitetään ohjelmaa niin ei nyt helvetissä haluta kääntää miljoonaa riviä koodia kun tekee vaikka pienen muutoksen. Make toimii niin, että se käännetään vain muuttuneet kohdat uudestaan niin kehittäminen on hurjasti nopeampaa. Make on aina tehty toimimaan POSIX -yhteensopivan komentotulkin kanssa, 70-luvulta saakka.
Ongelmasi taitaa olla se, että yrität käyttää Windowsia sellaiseen mihin Windowsia ei ole tarkoitettu. Windows on tarkoitettu sovellusten käyttöliittymiä varten ja siihen on sitä varten työkalut.MITÄ SOOPAA, IHAN NORMAALISTI SE ASENTUU.
- Anonyymi
Google kertoi että tuolla ollut kätevämpi tehdä ristiinkääntöä.
- Anonyymi
Tukeeko make-file monisäikeistystä, luulisi käyttiksen koodien kääntö kestävän yksi-säikeisenä tiedosto kerralla pienen ikuisuuden?
- Anonyymi
Yksittäisen modulin joutuu joka tapauksessa kääntämään yhdellä komennolla, jolloin säikeistys-ongelma ratkeaa itsestään, koska make voidaan komentaa käyttämään -j parametrilla(jobs) n kpl yhtäaikaista käännöstä. Riippuu käyttöjärjestelmästä onko nämä sitten säikeitä vai prosesseja. Tiedostojen riippuvuudet luovat automaattisesti sopivan hajautuspuun jolloin yleensä ottaen homma toimii ja stall-tilanteita ei synny. Käännösvaiheessa ajetaan useita säikeitä ja linkitys hoidetaan erillisenä yksisäikeisenä vaiheena, koska se on varsin nopea toimenpide.
Tuosta "perl-ohjelmoinnista" on sekä hyviä että huonoja kokemuksia. Esim. voidaan käyttää generaattoreita, joilla luodaan automaattisesti koodia matemaattisen mallin pohjalta. Ongelmia tulee vasta siinä vaiheessa, kun tuo perl-hässäkkä pitää portata uudelle alustalle, jolla ei ennestään ole käännöskirjastoja tarjolla ja toisaalta käännös vaati jotain kääntäjän erityisoptioita ollakseen tehokas. Esim. crc/tarkistussumman laskennan generointi säästää kyllä aikaa, mutta sen voi joutua koodaamaan silti uudestaan, jotta saisi yhdenmukaiset rajapinnat muuhun koodiin nähden.
Make on periaatteessa erittäin hyvä tapa kääntää ohjelmia, mutta sen tapa tuottaa c-kääntäjän käännöskomento on rajallisempi, kuin mitä esim. perl voi tarjota.
- Anonyymi
Voihan sen kysymyksen noinkin esittää.
Todellisuudessa voi kysyä, miksi linux -maailmassa yleensäkään käytetään C -kieltä, joka on niin alkeellinen ohjelmointikieli, ettei C -kielistä koodia saada käännettyä konekielelle ilman erillistä kääntöjärjestelmää, jota roolia usein hoitaa kombinaatio: autoconf / automake / make.
esim. Delphi on suunniteltu niin, ettei mitään erillistä kääntöjärjestelmää tarvita.
Delphin IDEssä kun painaa F9 (Compile) niin tuloksena on EXE -tiedosto (tai DLL -tiedosto, jos niin halutaan).
Delphi osaa ihan itse lukea käännösaikana (automaattinen linkkaus osana kääntämistä) kaikki tarvittavat tiedostot.
Delphin OmaProjekti.dpr -tiedostossa sen salaisuus, uses -lause, esim:
uses
Forms,
TestMF in 'C:\Data\koodit\TestMF.pas' {Form1},
Demo1 in 'C:\Data\koodit\Demo1.pas';
Tuosta Delphi saa suoraan tiedon, missä hakemistossa mikäkin tarvittava tiedosto on.
Tosin esim. Forms.pas -tiedoston osalta:
Delphi tietää itse, mihin hakemistoon Delphi on asennettu.
Siksi Delphi tietää itse, mistä hakemistosta Forms.pas löytyy, niinpä sitä ei tarvitse tuossa .dpr -tiedostossa erikseen kertoa.
Yleensä näin.
Toki, JOS siihen on jokin erillinen tarve, niin voi käyttää:
{$IFDEF erikoisversio1}
erikoisversio1_AddOns,
{$else}
{$ENDIF}
tuollaisen VOI laittaa osaksi .dpr -tiedostoa, JOS sellaiseen on jokin erityinen tarve.
Jos tuollaista erityistä tarvetta ei ole, niin jättää laittamatta.
Miksi C -kieli tarvitsee erillisen kääntöjärjestelmän, kun esim. Delphi ei sellaista mihinkään tarvitse.
Lisäksi: Delphissä käännösprosessi on erittäin nopea.
Silti Delphi kääntää aidoksi konekieleksi.
Se, onko Portege parempi kuin autoconf / automake / make, sitä en tiedä.
Monesti ainakin Windowsissa tuo autoconf / automake / make on yhtä helvettiä.
Ja silloinkin kun toimii, niin toimii todella hitaasti.
Hitauteen tosin löytyi syy:
gcc EI OLE C -kääntäjä (kuten moni luulee).
gcc on C -kääntäjän edustaohjelma. Olisiko ollut cc1.exe (MinGw-gcc:ssä) joka on se varsinainen C -kääntäjä.
MUTTA:
Syy hitauteen:
Windowsissa MinGw-gcc yrittää ajaa kaikkia näitä:
cc1.exe.bat
cc1.exe.com
cc1.exe.exe
cc1.exe.cmd
cc1.exe
Ja vasta viimeinen onnistuu. Eli aikaa tuhlataan neljän olemattoman tiedoston ajamisyritykseen.
Ja tuo autoconf vasta onkin hölmö systeemi.
Testing if C -compiler works .... Yes.
ja parisataa samantyyppistä testiä.
Eikä ollut osaamista TALLENTAA noiden testien tuloksia koneelle niin, että kun ajaa seuraavalle projektille autoconf ( ./configure ) niin osaisi hakea noista TALLENNETUISTA tiedoista vastaukset niihin kysymyksiin, jotka on jo aiemmin testattu, niin ei palaisi aikaa samojen testien toistamiseen loputtomiin.
Eikä tässä vielä kaikki:
Joissakin projekteissa on jo ennen ./configure -komennon ajamista ajettava jokin preconfigure tai mikä lie nimeltään ensin!
Jos yrittää suoraan ajaa ./configure -komennon, niin näissä projekteissa tuloksena on kasa virheilmoituksia, kun ilman tuota esikonfigurointia ei ole joko olemassa tai ainakaan oikeanmuotoisina tiedostoina olemassa niitä tiedostoja, joita tuo ./configure -komento tarvitsisi - jolloin ./configure -komento päättyy kasaan virheilmoituksia.
Tässä vaiheessa loppuu normaalit keinot kuin seinään!
Ainoaksi avuksi jää:
Voi yrittää manuaalisesti kääntää .c -loppuisia tiedostoja, ja jokaisessa vastassa
#include "jotaina.h"
ja/tai
#include <jotainb.h>
-tyyppinen "koodaajan helvetti".
Kun jotkut ohjelmat on tehty niin ikävästi, että tarvittavia .h -tiedostoja ei ole, vaan niiden sijasta on esim. jotakin.esih (ok, tuo ".esih" on oma nimitykseni, kun en muista mikä se virallinen tiedostopääte noille on)
ja sitten pitäisi ajaa esim. Python -skripti, joka lukee nuo jotakin.esih -tiedostot, ja luo niistä jotakin.h -tiedoston jne.
Ilmeisesti tuo jotakin.esih -tiedosto EI ole C -kääntäjälle sellaisenaan kelpaava (eli ei oikeasti ole edes C -kieltä) vaan on jotain hieman C -kieltä muistuttavaa kieltä, jonka tuo Python -skripti sitten muokkaa C -kieliseksi.
Kuinkahan monta % noista muka "C -projekteista" on tuollaista esi-C -kieltä, josta olisi tarkoitus jollain Python -skriptillä (tai muulla vastaavalla skriptikielellä tehdyllä skriptillä) kääntää ne C -kieleksi, joka sitten kelpaisi C -kääntäjälle.
Ja joskus (usein) käy niin, että se skripti ei osaa hommiaan, eli ehkä toimisi linuxissa mutta Windowsissa ei osaa tehdä oikeita asioita.
En tiedä, miksi niin moni jatkaa C -kielen käyttöä, vaikka kieli tuntuu olevan niin alkeellinen, ettei sillä ilman erillistä kääntöjärjestelmää mitään tee.
Ehkä C -kielen käyttö on eräänlainen uskonto, jolla saadaan aikaiseksi esim. puskurin ylivuotohaavoittuvuuksia.
Esim. HeartBleed -haavoittuvuutta ei olisi koskaan tapahtunut, jos tuo kyseinen kommunikaatiokirjasto olisi koodattu Delphillä (ja ehkä tehty siitä myös Kylix- ja FreePascal -yhteensopiva).
Mutta 1 asia on 100% varma: Niin kauan kuin C -kielen käyttöä jatketaan, puskurin ylivuotohaavoittuvuuksia tulee aina olemaan- Anonyymi
Tässä unohtuu se, että delphi/fpc kääntäjä on aivan erilainen kuin cc-kääntäjä. Se näkyy jopa kielessä, koska on tarve tehdä delphille kääntäjän kannalta one-pass koodia. cc-kääntäjä pystyy käymään koodia useaan kertaan läpi, josta seuraa hitautta, mutta samalla vältytään delphin ongelmilta.
btw. puskurin ylivuotoon on helppo lääke: Kirjoittaa malloc-funktion itse. Nuo delphissä tehdyt puskurin suojaus-tavat aiheuttaa koodiin turhaa hitautta, koska niitä ei voi kytkeä lopullisesta versiosta pois päältä. Toisekseen kukaan ei kirjoita koodia pelkästään delphillä vaan suuri osa kirjastoista on c-kielellä koodattuja eli suomeksi: koodi ei olekaan ylivuodoilta suojattua kokonaisuudessaan.
Ketjusta on poistettu 1 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Hengenvaaralliset kiihdytysajot päättyivät karmealla tavalla, kilpailija kuoli
Onnettomuudesta on aloitettu selvitys. Tapahtuma keskeytettiin onnettomuuteen. Tapahtumaa tutkitaan paikan päällä yhtei1726213- 1471724
- 1131518
- 511270
Suureksi onneksesi on myönnettävä
Että olen nyt sitten mennyt rakastumaan sinuun. Ei tässä mitään, olen kärsivällinen ❤️46932Möykkähulluus vaati kuolonuhrin
Nuori elämä menettiin täysin turhaan tällä järjettömyydellä! Toivottavasti näitä ei enää koskaan nähdä Kauhavalla! 😢29860Älä mies pidä mua pettäjänä
En petä ketään. Älä mies ajattele niin. Anteeksi että ihastuin suhun varattuna. Pettänyt en ole koskaan ketään vaikka hu97846Reeniähororeeniä
Helvetillisen vaikeaa työskennellä hoitajana,kun ei kestä silmissään yhtään läskiä. Saati hoitaa sellaista. Mitä tehdä?5799Tarvitsemme lisää maahanmuuttoa.
Väestö eläköityy, eli tarvitsemme lisää tekeviä käsiä ja veronmaksajia. Ainut ratkaisu löytyy maahanmuutosta. Nimenomaan226752- 41749