Ihmettelin, kun knoppix 5.3.1-DVD -versiossa CD ja DVD -levyjen poltto on epäluotettavaa.
Selvitin asiaa, ja selvisi, että wodim ei ole yhtä laadukas kuin cdrecord.
http://en.wikipedia.org/wiki/Wodim
http://en.wikipedia.org/wiki/Cdrecord
imuroin sitten tämän:
ftp://ftp.berlios.de/pub/cdrecord/ALPHA/cdrtools-beta.tar.gz
loin sille kansion ja purin sen komennolla:
gzip -d < /media/sda12/cdimages/cdrtools-beta.tar.gz | tar -xpf -
(ohjeet nimenomaan kehottavat purkamaan sen noin, eikä käyttämään muita purkutapoja !)
ohjeissa myös mainittiin ettei linuxien vakio make toimi tuon kanssa oikein vaan kehotti käyttämään smake:a
varmistin vielä että smake on edes sama ohjelma kuin tuossa tarkoitetaan:
$ smake --version
Smake release 1.2a23 (i686-pc-linux-gnu) Copyright (C) 1985, 87, 88, 91, 1995-2004 Jörg Schilling
ok, siispä seuraavaksi:
smake
...
MUTTA, eipä osannut smake kääntää tuota ohjelmapakettia oikein !
En tiedä, miksi linux -maailmassa tuo on enemmän sääntö kuin poikkeus että yhden sun toisenkin ohjelman kohdalla kääntäminen ei onnistu ilman linuxgurun taitoja !
Yksi ohjelma haluaa käyttää ./configure ja ./make -komentoja, toinen taas tuomitsee nuo auttamattoman vanhentuneiksi, ja tarjoaa omaa systeemiään tilalle, mutta molemmilla tavoilla aina löytyy ohjelmia, jotka ei vaan käänny oikein !
Siispä linuxille pitäisi kehittää parempi automaattinen käännösjärjestelmä !
suht yksinkertaisten C (ja ehkä myös C ) -ohjelmien osalta osaisin ehkä jopa itsekin toteuttaa paremman käännösjärjestelmän. Mutta nuo jättiprojektit, joita nykyinenkään systeemi ei aina osaa kääntää, niiden suhteen tarvittaisiin apua !
Haluaako kukaan laatia omasta C tai C -linuxohjelmastaan versiota, joka käyttäisi uutta ja fiksumpaa käännössysteemiä ?
Siis sillä oletuksella, että olen ensin laatinut ja julkaissut paremman käännösjärjestelmän ja laittanut sille sinänsä "hello, world" -tasoisen ohjelman malliohjelmaksi automaattisine käännösmäärittelyinenn, mutta kuitenkin niin, että perinteisestä "hello, world":istä poiketen tuo malliohjelma sisältää useita .c ja .h -tiedostoja ja niiden keskinäisiä riippuvuuksia jotta tulee osoitetuksi että homma toimii myös niiden osalta oikein.
Samalla tulee mahdolliseksi kunnollisen ja laadukkaan GUI IDE:n (=integrated development environment) kehittäminen myös C/C -kielille linuxissa.
Toistaiseksihan tuollainen laadukas GUI IDE linuxissa on mahdoton siitä tavasta johtuen, joilla käännösjärjestelmät on tähän asti tehty.
Ai mitäkä tämä tarkoittaa ?
No, laadukas GUI IDE sisältää ilman muuta toiminnon, jossa mihin tahansa sanaan (vaikkapa laskuri) voi CTRL -klikata hiirellä, ja IDE siirtyy oikeaan kohtaan oikeassa tiedostossa (siis tarvittaessa avaa toisen tiedoston, vaikkapa globaalit.h), josta löytyy esim:
int laskuri;
Nykyiset käännösjärjestelmät ikävä kyllä tekevät tuosta mahdotonta !
Miksikö ?
Koska koodissa voi lukea vaikkapa
#ifdef uusiversio
#include globaalit_uusi.h
#else
#include globaalit.h
#endif
mutta ongelmana on se, ettei missään tiedostossa lue:
#define uusiversio
- tämä ei kuitenkaan automaattisesti tarkoita, että aina olisi oikein avata tuota laskuri:a klikattaessa tuo
globaalit.h
sillä make:n yhteydessä voikin kirjoittaa:
make -Duusiversio
jolloin käännökseen ei otetakaan mukaan globaalit.h vaan globaalit_uusi.h, jossa voi lukea vaikkapa:
long long int laskuri;
parempi käännösjärjestelmä ei salli make:n yhteydessä annettavia ehdollisia määrittelyjä, vaan sen sijaan voi olla vaikkapa
projektimaarittelyt.h
jossa sitten voi lukea joko:
#define uusiversio
TAI
#undef uusiversio
TAi sitten
// #define uusiversio - pois käytöstä
kun tuontapaisten määritysten anto komentorivillä estetään ja vaaditaan, että ne laitetaan tiedostoon, tällöin IDE tietää aina, mitkä (include-) tiedostot kuuluvat oikeasti projektiin ja mitkä eivät.
useiden käyttöjärjestelmien tukeminenkin onnistuu silti muulla tavalla, kunhan homma suunnitellaan alusta asti oikein !
Selvitin asiaa, ja selvisi, että wodim ei ole yhtä laadukas kuin cdrecord.
http://en.wikipedia.org/wiki/Wodim
http://en.wikipedia.org/wiki/Cdrecord
imuroin sitten tämän:
ftp://ftp.berlios.de/pub/cdrecord/ALPHA/cdrtools-beta.tar.gz
loin sille kansion ja purin sen komennolla:
gzip -d < /media/sda12/cdimages/cdrtools-beta.tar.gz | tar -xpf -
(ohjeet nimenomaan kehottavat purkamaan sen noin, eikä käyttämään muita purkutapoja !)
ohjeissa myös mainittiin ettei linuxien vakio make toimi tuon kanssa oikein vaan kehotti käyttämään smake:a
varmistin vielä että smake on edes sama ohjelma kuin tuossa tarkoitetaan:
$ smake --version
Smake release 1.2a23 (i686-pc-linux-gnu) Copyright (C) 1985, 87, 88, 91, 1995-2004 Jörg Schilling
ok, siispä seuraavaksi:
smake
...
MUTTA, eipä osannut smake kääntää tuota ohjelmapakettia oikein !
En tiedä, miksi linux -maailmassa tuo on enemmän sääntö kuin poikkeus että yhden sun toisenkin ohjelman kohdalla kääntäminen ei onnistu ilman linuxgurun taitoja !
Yksi ohjelma haluaa käyttää ./configure ja ./make -komentoja, toinen taas tuomitsee nuo auttamattoman vanhentuneiksi, ja tarjoaa omaa systeemiään tilalle, mutta molemmilla tavoilla aina löytyy ohjelmia, jotka ei vaan käänny oikein !
Siispä linuxille pitäisi kehittää parempi automaattinen käännösjärjestelmä !
suht yksinkertaisten C (ja ehkä myös C ) -ohjelmien osalta osaisin ehkä jopa itsekin toteuttaa paremman käännösjärjestelmän. Mutta nuo jättiprojektit, joita nykyinenkään systeemi ei aina osaa kääntää, niiden suhteen tarvittaisiin apua !
Haluaako kukaan laatia omasta C tai C -linuxohjelmastaan versiota, joka käyttäisi uutta ja fiksumpaa käännössysteemiä ?
Siis sillä oletuksella, että olen ensin laatinut ja julkaissut paremman käännösjärjestelmän ja laittanut sille sinänsä "hello, world" -tasoisen ohjelman malliohjelmaksi automaattisine käännösmäärittelyinenn, mutta kuitenkin niin, että perinteisestä "hello, world":istä poiketen tuo malliohjelma sisältää useita .c ja .h -tiedostoja ja niiden keskinäisiä riippuvuuksia jotta tulee osoitetuksi että homma toimii myös niiden osalta oikein.
Samalla tulee mahdolliseksi kunnollisen ja laadukkaan GUI IDE:n (=integrated development environment) kehittäminen myös C/C -kielille linuxissa.
Toistaiseksihan tuollainen laadukas GUI IDE linuxissa on mahdoton siitä tavasta johtuen, joilla käännösjärjestelmät on tähän asti tehty.
Ai mitäkä tämä tarkoittaa ?
No, laadukas GUI IDE sisältää ilman muuta toiminnon, jossa mihin tahansa sanaan (vaikkapa laskuri) voi CTRL -klikata hiirellä, ja IDE siirtyy oikeaan kohtaan oikeassa tiedostossa (siis tarvittaessa avaa toisen tiedoston, vaikkapa globaalit.h), josta löytyy esim:
int laskuri;
Nykyiset käännösjärjestelmät ikävä kyllä tekevät tuosta mahdotonta !
Miksikö ?
Koska koodissa voi lukea vaikkapa
#ifdef uusiversio
#include globaalit_uusi.h
#else
#include globaalit.h
#endif
mutta ongelmana on se, ettei missään tiedostossa lue:
#define uusiversio
- tämä ei kuitenkaan automaattisesti tarkoita, että aina olisi oikein avata tuota laskuri:a klikattaessa tuo
globaalit.h
sillä make:n yhteydessä voikin kirjoittaa:
make -Duusiversio
jolloin käännökseen ei otetakaan mukaan globaalit.h vaan globaalit_uusi.h, jossa voi lukea vaikkapa:
long long int laskuri;
parempi käännösjärjestelmä ei salli make:n yhteydessä annettavia ehdollisia määrittelyjä, vaan sen sijaan voi olla vaikkapa
projektimaarittelyt.h
jossa sitten voi lukea joko:
#define uusiversio
TAI
#undef uusiversio
TAi sitten
// #define uusiversio - pois käytöstä
kun tuontapaisten määritysten anto komentorivillä estetään ja vaaditaan, että ne laitetaan tiedostoon, tällöin IDE tietää aina, mitkä (include-) tiedostot kuuluvat oikeasti projektiin ja mitkä eivät.
useiden käyttöjärjestelmien tukeminenkin onnistuu silti muulla tavalla, kunhan homma suunnitellaan alusta asti oikein !
Vastaukset 3
Vanhimmat
Ei valmiin sorsan kääntämisessä mitään ideä tarvita. Tarkoitushan on vain kääntää.
Yleensä käännöksen epäonnistumiseen on syynä headerien puuttuminen. Joskus saa todella metsästää että kaikki tarvittavat löytyvät.Toinen vaiva on se että vaaditaan liian uusia kirjastoja tai ohjelmia. Jopa ilman syytä.
"Ei valmiin sorsan kääntämisessä mitään ideä tarvita."
Väärin! - kyllä tarvitaan !
Linuxin tapa:
smake aiheuttaa sen, että teksti vilistää tekstiterminaalissa sellaista vauhtia, ettei sitä kukaan kerkeä lukea.
Lopulta palataan komentokehotteeseen, ja backscroll -loki on ainoa paikka mistä voi edes yrittää kaivaa tietoa, mikä meni pieleen.
Eli suoraan ruudulla ei enää näy mitään vihjettä ongelman syystä, ne rivit ovat jo kaukana takanapäin.
backscroll -lokista voi siis yrittää katsoa, mikä meni pieleen. Ja pari puuttuvaa viittausta siellä näyttää toistuvankin. Mutta kun se loki ei ole pituudeltaan ääretön, niin ennen lokin alkua voi olla lisää puuttuvia viittauksia - joita ei näe mitenkään.
Miksi tällaisia ½valmiita ohjelmia yleensä julkaistaan ?
Windows -kehitysvälineiden tapa toimia:
Cannot find units A, B, C , E
Compilation failed.
Kyllä näistä tuo jälkimmäinen on paljon selkeämpi.
Ja voisi olettaa, että jos ohjelma on tekijänsä mielestä valmis, niin esim. syntax erroreita ei pitäisi olla, vaan ainoastaan puuttuvia uniteja, ja ne windowsissa näkeekin selkeästi yhdellä vilkaisulla.
googletus selvitti, että pitää olla riittävän uusi smake !
Siis TÄH ?
Miksi pitää laatia ohjelmastaan sellainen, että linux -jakelun mukana tullut make ei kelpaa vaan pitää olla saman tekijän oma smake ja sitten siitäkään ei vanhempi versio kelpaa ?!
Jos ongelma todella korjautuu uudemmalla smakella, niin hyvä näin, mutta jos IDE olisi omaa käsialaani, tällaisia ongelmia ei pitäisi edes syntyä.
Jotain linuxille ominaisessa tavassa toimia ja työkaluissa on vikana, jos sellaisenaan tekijän jäljiltä oleva paketti ei suostu kääntymään.
Tarkoitus olisi siis tuoda myös C ja C -ohjelmointiin samanlainen UNIT -järjestelmä kuin delphissä on.
Se on selkeä ja hyväksi havaittu, eikä aiheuta yllättäviä ongelmia.
Tässä ilmeisesti vääriä/puuttuvia hakemistoviittauksia.
Delphissä säännöt ovat selkeät:
1) Delphin mukana tulevat unitit löytyvät aina automaattisesti oikeasta paikasta (jos ei sitten käyttäjä itse sotke delphin asetuksia - uudelleen/korjausasennus korjaa tämänkin mahd. hölmöilyn seuraukset)
2) projektitiedoston kanssa samassa hakemistossa olevat unitit löytyvät myös automaattisesti
3) projektioptioissa voi laittaa listan hakemistoja, joista uniteja etsitään listan mukaisessa järjestyksessä
4) jos projektitiedostossa on rivi:
uses
esimerkki in 'F:\joku\muu\hakemisto\esimerkki.pas',
niin silloin kun yksittäisessä unitissa on:
uses
esimerkki;
niin delphi osaa automaattisesti ladata tuon F:\joku\muu\hakemisto\esimerkki.pas
C -kielessä tietenkin asiaa monimutkaistaa tämä:
siinä missä objectpascalilla on:
unit esimerkki; // tiedostossa F:\joku\muu\hakemisto\esimerkki.pas
jossa on sitten interface ja implementation -osat
niin C:ssä onkin erikseen;
esimerkki.h
esimerkki.c
eikä gcc:ssä ole oletuksena "projekti.prj" -tiedostoa, jossa lukisi jotain tämäntapaista:
[esimerkki]
esimerkki.h=/home/matti/projektit/modulit2/esimerkki.h
esimerkki.c=/home/matti/projektit/modulit2/esimerkki.c
Tällainen IDE pitää saada C/C -ohjelmointiin, jossa perussäännöt ovat kuten Delphissä, mutta
delphin
esimerkki in 'F:\joku\muu\hakemisto\esimerkki.pas',
sijasta onkin tuo
[esimerkki]
esimerkki.h=/home/matti/projektit/modulit2/esimerkki.h
esimerkki.c=/home/matti/projektit/modulit2/esimerkki.c
tuossa voisi olla vielä esim.
lang=C
tai
lang=C
ja joissain tapauksissa vaikkapa:
interfaceonly=true // jos on esim. kirjastoimport.h ilman vastaavaa kirjastoimport.c -tiedostoa
Tällöin jos on viittaus väärään hakemistonimeen tai yritetään viitata tiedostoon pelkällä tiedostonimellä ilman polkunimeä, niin korjaukseksi riittää selvittää, missä ko. tiedosto on
esim:
locate # muista käyttää root -oikeuksin updatedb -komentoa, jos tiedosto on lisätty viimeisen automaattisesti ajastetun updatedb:n jälkeen
grep
tai
mc:n tai konquerorin "find file" -toiminto
ja sitten lisää tuollaisen
[esimerkki]
esimerkki.h=/home/matti/projektit/modulit2/esimerkki.h
esimerkki.c=/home/matti/projektit/modulit2/esimerkki.c
projektitiedostoon.
Näin saataisiin linuxiinkin sitä helppokäyttöisyyttä, mistä windowsissa on voitu nauttia jo Delphi 1.0:sta alkaen eli vuodesta 1995, eli näissä asioissa linux on jo nyt 15 vuotta windowsia jäljessä, eikä linuxdistrojen tekijät ilmeisesti oma-aloitteisesti aio korjata asiaa vieläkään.
Tuollaisen ainakin vaatimattoman version IDE:n osaisin ehkä itsekin toteuttaa, mutta sen testaaminen jollain vähän isommalla projektilla vaatisi jonkun projektin omistajan yhteistyöhalua asiassa !
Kyllä siinä tar-pallossa on aina aivan kaikki mukana mikä voikin olla. Ja kaikki löytyy ilman mitään etsintää. Mutta siinä ei voi olla tietoa koneella olevista ohjelmista. Vaikka jonkin tarvittava kirjasto on asennettuna niin kääntö ei onnistu ilman tuon kirjaston headereita ei niitä voi olla siinä paketissa mukana. Se jää väkisinkin sille, joka yrittää kääntää.
Kokeilin mitä tuo cdrtools-paketti kääntyy.
"tar xzf" komennolla paketti auki
"./configure" sanoi että käskytä vain make
"make" käänsi että pörinä kävi
"make install" jätin tekemättä. Tarkoitus oli vain kokeilla käännöstä.