---

Hejsa

Jeg forsøger i øjeblikket at bruge c++ under linux, og det er
umiddelbart sværere
end jeg troede. Jeg kommer fra java verdenen og har ellers kun lært lidt
c++ til
arbejdsbrug på windows, så jeg er lidt forvent hvad angår IDE's og ligende.

Jeg har derfor søgt lidt på nettet, og da jeg kører gnome har jeg
installeret anjuta+glade
samt diverse lib**mm bilioteker.

Men selv når jeg opretter et simpelt terminal/konsol (tomt?) c++ project
i anjuta, så bliver jeg
fuldstændigt overvældet af mængden af filer den laver. Den laver 37
filer for et simpelt projekt,
og jeg havde forventet max 3.

Er der nogen her som kan fortælle mig hvad alle de filer skal gøre godt
for og hvordan de bruges?

Jeg havde forventet noget i retning af:

src/main.cpp // main c++ filen
<projectnavn>.project // projectfilen til IDE'et
<buildfil> // en fil ala et ant build script til at bygge projektet
udenom IDE'et.

Men I stedet har jeg fået:

// disse filer er vist bare tekstfiler som det er meningen jeg skal
skrive/udfylde
AUTHORS
ChangeLog
NEWS
README
TODO

// næsten de(n) projektfiler jeg regnede med. Det ene er åbenbart en
backup hvilket er ok
// men hvorfor er der ikke backup af den anden.

VideoStore.prj
VideoStore.prj.bak
VideoStore.pws

// Den main fil jeg havde forventet. Plus noget andet fyld.
src/Makefile
src/Makefile.am
src/Makefile.in
src/main.cc


// Nu begynder det at gå galt for mig, Hvad er er alle disse filer ?
// - hvad gør de ?, hvorfor er de nødvendige ?

COPYING -> /usr/share/automake-1.4/COPYING
INSTALL -> /usr/share/automake-1.4/INSTALL
install-sh -> /usr/share/automake-1.4/install-sh
missing -> /usr/share/automake-1.4/missing
mkinstalldirs -> /usr/share/automake-1.4/mkinstalldirs

Makefile
Makefile.am
Makefile.in
acconfig.h
acinclude.m4
aclocal.m4
autogen.sh
config.cache
config.guess
config.h
config.h.in
config.log
config.status
config.sub
configure
configure.in
conftest
conftest.c
conftest.o
include
libtool
ltmain.sh
setup-gettext
stamp-h
stamp-h.in

Umiddelbart virker alle disse filer en smule lavteknisk, og ikke særligt
strømlinet.
Håber der er nogen som kan få mig til at se lyset, så det hele virker
mere logisk.

mvh
henrik

ps. FUT er sat til d.e.p.C

---

On Thu, 12 Jun 2003 22:34:33 +0200
Henrik Lynggaard <henrik@lynggaard.org> wrote:

> Jeg har derfor søgt lidt på nettet, og da jeg kører gnome har jeg
> installeret anjuta+glade
> samt diverse lib**mm bilioteker.

Dette er ikke et C++ spørgsmål, men omhandler derimod Anjuta, så jeg vil
anbefale dig at spørge på en anjuta "mailling liste"/forum/newsgroup.

mvh
socketd

---

Socketd <db@traceroute.dk> writes:

> On Thu, 12 Jun 2003 22:34:33 +0200
> Henrik Lynggaard <henrik@lynggaard.org> wrote:
>
>> Jeg har derfor søgt lidt på nettet, og da jeg kører gnome har jeg
>> installeret anjuta+glade
>> samt diverse lib**mm bilioteker.
>
> Dette er ikke et C++ spørgsmål, men omhandler derimod Anjuta, så jeg vil
> anbefale dig at spørge på en anjuta "mailling liste"/forum/newsgroup.

Måske får han bedre svar der, men spørgsmålet er også on-topic her.
Fra fundatsen til denne gruppe:

>>> Diskussion af specifikke værktøjer, compilere, extensions og
>>> libraries til de tre sprog, som for eksempel Visual C++,
>>> __atribute__, dbx eller OWL, er også velkomne.

---

"Henrik Lynggaard" <henrik@lynggaard.org> wrote in message
news:3ee8e362$0$32445$edfadb0f@dread16.news.tele.dk...
> Hejsa
>
> Jeg forsøger i øjeblikket at bruge c++ under linux, og det er
> umiddelbart sværere
> end jeg troede. Jeg kommer fra java verdenen og har ellers kun lært lidt
> c++ til
> arbejdsbrug på windows, så jeg er lidt forvent hvad angår IDE's og
ligende.


En mulighed er at du henter Kylix hos Borland. Den er gratis i open udgaven,
og der får du en IDE som du kender. Du har mulighed for at bede Kylix om at
lave enten Pascal eller C. Du kan desuden hente Delphi til Windows, således
at du flytte din kildekode til Windows, og blot re-compile for at afvikle
dit program der. Installationen og anvendelsen af Kylix er som hentet fra
windows (dvs. godt for dem som er vant til det).

Jørn

---

Jørn Hundebøll wrote:

> En mulighed er at du henter Kylix hos Borland. Den er gratis i open
> udgaven, og der får du en IDE som du kender.

Kan man kompilere med gcc? Jeg bruger en source-baseret distribution, så
det ville være *noget* træls at skulle downloade Kylix før jeg kunne
installere et lille program. Det ville heller ikke kunne gøres
automatisk, da Kylix' EULA vistnok kræver interaktion.

Hvis man vil have noget der ligner Kylix lidt, så prøv Qt Designer. Den
er ikke en egentlig IDE endnu, men den nærmer sig.

--
PeKaJe

It may be that your whole purpose in life is simply to serve as a
warning to others.

---

"Peter Jensen" <jdogh001@sneakemail.com> wrote in message
news:3ee8f34e$0$13211$edfadb0f@dread15.news.tele.dk...
> Jørn Hundebøll wrote:
>
> > En mulighed er at du henter Kylix hos Borland. Den er gratis i open
> > udgaven, og der får du en IDE som du kender.
>
> Kan man kompilere med gcc? Jeg bruger en source-baseret distribution, så
> det ville være *noget* træls at skulle downloade Kylix før jeg kunne
> installere et lille program. Det ville heller ikke kunne gøres
> automatisk, da Kylix' EULA vistnok kræver interaktion.


Men jeg ved ikke om jeg forstår dit spørgsmål korrekt ?


Hvis det "kun" er for at installere, skal du vel "bare" bruge gcc - det bør
virke out-off-the-box. Ideen med Kylix er kun god, hvis du selv ønsker at
lave programmer. Du får en IMHO god brugerflade (IDE), hvor du kan
singlesteppe, watch variable, opbygge forms, og det minder stadig lidt om de
gode gamle Borland Pascal/C dage. Det rigtige smarte er at du kan flytte
koden uden ændringer til Windows via Delphi.


Jørn

---

Jørn Hundebøll wrote:

>>> En mulighed er at du henter Kylix hos Borland. Den er gratis i open
>>> udgaven, og der får du en IDE som du kender.
>>
>> Kan man kompilere med gcc? Jeg bruger en source-baseret distribution,
>> så det ville være *noget* træls at skulle downloade Kylix før jeg
>> kunne installere et lille program. Det ville heller ikke kunne gøres
>> automatisk, da Kylix' EULA vistnok kræver interaktion.
>
> Men jeg ved ikke om jeg forstår dit spørgsmål korrekt ?
>
> Hvis det "kun" er for at installere, skal du vel "bare" bruge gcc -
> det bør virke out-off-the-box.

Men gør det rent faktisk det? Jeg mener at Kylix programmer *ikke* kan
compileres med gcc. Jeg kan dog ikke huske det, da det er noget tid
siden jeg brugte det sidst. Er der nogen der kan be- eller afkræfte det?
Jeg er ikke lige i humør til at støve Kylix op igen ...

> Ideen med Kylix er kun god, hvis du selv ønsker at lave programmer.

Vim, make og auto*. Platform uafhængigt.

> Du får en IMHO god brugerflade (IDE),

Uden tvivl. Der findes dog også OSS IDE'er, hvis jeg forstår det
rigtigt. Det er lidt akedemisk for mig, da jeg ikke bruger dem i Linux.

> hvor du kan singlesteppe, watch variable,

gdb med ddd som frontend.

> opbygge forms,

Qt Designer.

> og det minder stadig lidt om de gode gamle Borland Pascal/C dage. Det
> rigtige smarte er at du kan flytte koden uden ændringer til Windows
> via Delphi.

Det *er* da smart. Kan man ikke gøre det samme med GTK, som er Open
Source, samt lidt fornuftig programmering?

--
PeKaJe

QOTD:
   "It's a cold bowl of chili, when love don't work out."

---

"Peter Jensen" <jdogh001@sneakemail.com> wrote


[8<8<8<]
> Jeg mener at Kylix programmer *ikke* kan
> compileres med gcc. Jeg kan dog ikke huske det, da det er noget tid
> siden jeg brugte det sidst. Er der nogen der kan be- eller afkræfte det?

Det kommer an på hvad man mener med Kylix programmer.

Kylix 3 understøtter 2 sprog:
* Delphi Language (Object Pascal)
* C++ (tilføjet nogle sprog udvidelser)

Der findes vist ikke nogen compiler i gcc, der kan oversætte Delphi
Language.

Kylix 3 kan oversætte Standard C++ programmer, som også kan oversættes med
g++. Det gør jeg rutine mæssigt.
Hvis man anvender de sprogudvidelser, der er til C++ kan man ikke oversætte
programmet med g++.
Man bruger f.eks. de sprogudvidelser, når man laver brugergrænseflade med
RAD delen af Kylix (som bruger Borland klassebiblioteket CLX).

Det svarer i øvrigt fuldstændigt til hvordan det forholder Borland
C++Builder på MS-Windows.

Venlig hilsen

Mogens Hansen

---

> Vim, make og auto*. Platform uafhængigt.

emacs :D


>>hvor du kan singlesteppe, watch variable,
>
> gdb med ddd som frontend.

gvd (gnu visual debugger) kan anbefales over ddd. ddd har det med at gå
ned, eller slet ikke virke.

I øvrigt virker det som en mærkværdig fremgangsmåde at installere Kylix,
for at compilere programmer, der er skrevet til gcc (det vil en
source-baseret distribution typisk være). Det kan der vist kun kommme
ballade ud af.



Med venlig hilsen,
\\Mikkel Gjøl

---

> Jørn Hundebøll wrote:
>> En mulighed er at du henter Kylix hos Borland. Den er gratis i open
>> udgaven, og der får du en IDE som du kender.

Peter Jensen wrote:
> Kan man kompilere med gcc?

Kylix programmer kan skrives i standard C++, men ikke hvis man vil bruge
GUI. Så bruger der Kylix-specifikke udvidelser til sproget, og så kan det
ikke kompileres med gcc.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

---

Lars Dybdahl wrote:

>>> En mulighed er at du henter Kylix hos Borland. Den er gratis i open
>>> udgaven, og der får du en IDE som du kender.
>>
>> Kan man kompilere med gcc?
>
> Kylix programmer kan skrives i standard C++, men ikke hvis man vil bruge
> GUI. Så bruger der Kylix-specifikke udvidelser til sproget, og så kan det
> ikke kompileres med gcc.

Det var hvad jeg tænkte, men jeg ville lige have det bekræftet. Siden
Kylix' største fordel er cross-platform GUI programmering, så må man
konkludere at det måske ikke er så velegnet til Open Source udvikling,
da det kræver en noget "fyldig" compiler med en restriktiv licens for at
kunne compiles. Det giver jo så komplikationer på source-baserede
distributioner.

Til Closed Source udvikling vil jeg dog sige at Kylix er glimrende.
Linux er begyndt at blive et lukrativt marked for kommercielle
udviklere, så det er helt klart en fordel at man (i teorien da) kan
skrive en gang og compile det til to platforme. Borland har forstået at
udnytte situationen. Man kan jo håbe at andre snart følger trop

--
PeKaJe

Those who have some means think that the most important thing in the
world is love. The poor know that it is money. -- Gerald Brenan

---

Peter Jensen wrote:
> Det var hvad jeg tænkte, men jeg ville lige have det bekræftet. Siden
> Kylix' største fordel er cross-platform GUI programmering, så må man
> konkludere at det måske ikke er så velegnet til Open Source udvikling,
> da det kræver en noget "fyldig" compiler med en restriktiv licens for at
> kunne compiles. Det giver jo så komplikationer på source-baserede
> distributioner.
Borland mener jo åbenbart at Kylix er god til open source, ellers ville
Kylix OE vel ikke være begrænset til GPL-programmer. Det er jo heller
ikke alle som absolut vil compilere alt med gcc. De fleste har ikke
noget imod binære filer og er ligeglade med hvilken compiler der blev
brugt. Jeg har heller ikke noget imod at downloade Kylix, hvilket jeg
har gjort flere gange.

Ivan Johansen

---

Ivan Johansen wrote:

>> Det var hvad jeg tænkte, men jeg ville lige have det bekræftet. Siden
>> Kylix' største fordel er cross-platform GUI programmering, så må man
>> konkludere at det måske ikke er så velegnet til Open Source
>> udvikling, da det kræver en noget "fyldig" compiler med en restriktiv
>> licens for at kunne compiles. Det giver jo så komplikationer på
>> source-baserede distributioner.
>
> Borland mener jo åbenbart at Kylix er god til open source, ellers
> ville Kylix OE vel ikke være begrænset til GPL-programmer.

Har Borland ikke lignende udgaver af deres Windows programmer? Jeg
tænker her på versioner der udelukkende er til non-commercial brug? I så
fald svarer det jo lidt til hvad Open Source er for Linux.

Men misforstå mig endelig ikke. Jeg mener bestemt at Kylix er et skridt
i den rigtige retning. Jeg mener bare også at der kan være problemer med
den i forbindelse med Open Source udvikling. Man bør I hvert fald tænke
sig godt om, da det er træls at skulle skifte udviklingsmiljø.

> Det er jo heller ikke alle som absolut vil compilere alt med gcc.

Men hvis man laver et Kylix program, så er man *afhængig* af én
leverandør, uden hvilken projektet skal skrives meget om. Borland vil
nok kunne findes som firma i mange år, men der er ingen garantier. Jeg
har ikke studeret Kylix licensen meget, men jeg vil stadig tro at gcc er
mere fremtidssikret, da den giver dig betydeligt flere rettigheder.

> De fleste har ikke noget imod binære filer og er ligeglade med hvilken
> compiler der blev brugt.

"De fleste" ... Måske. Igen, jeg har ikke undersøgt Kylix specielt meget
for nyligt, men hvordan klarer den sig på andre arkitekturer end x86? En
betydelig del af Linux brugerne kører på PPC, Sparc, Alpha eller anden
hardware. Jeg ved at gcc kan compile til disse platforme. Kan Kylix?

Hvad med optimeringsflagene? Kan man optimere til en specifik
processormodel i Kylix? Det kan jo f.eks. have betydning i visse
beregningstunge grafiske programmer.

> Jeg har heller ikke noget imod at downloade Kylix, hvilket jeg har
> gjort flere gange.

Jeg har nu heller ikke specielt meget imod det, hvis det er for at
skulle bruge Kylix til andet end at compile. Jeg siger dog også kun at
det giver unødvendige komplikationer på source-baserede distributioner.

Alle den slags overvejelser skal man gøre før man beslutter sig på en
bestemt udviklingsplatform. Valget er op til udvikleren, men det skal
være et *informeret* valg.

Jeg fornemmer forresten at vi har været igennem denne snak før

--
PeKaJe

Okay ... I'm going home to write the "I HATE RUBIK's CUBE HANDBOOK FOR
DEAD CAT LOVERS" ...

---

Peter Jensen <jdogh001@sneakemail.com> writes:

> Alle den slags overvejelser skal man gøre før man beslutter sig på en
> bestemt udviklingsplatform. Valget er op til udvikleren, men det skal
> være et *informeret* valg.

Tjoo men hvis jeg for eksempel valgte at distribuere de af mine
programmer som er skrevet i SML ville det da også give problemer
hvis du skulle oversætte dem på din source baserede distro. Du
skulle jo først ud og finde en oversætter til dem og der efter
konfigurere dem.

Martin

--
Besøg http://adsltips.crunzh.com for guider
til ADSL og opsætning af CISCO router.

---

Martin Schultz wrote:

>> Alle den slags overvejelser skal man gøre før man beslutter sig på en
>> bestemt udviklingsplatform. Valget er op til udvikleren, men det skal
>> være et *informeret* valg.
>
> Tjoo men hvis jeg for eksempel valgte at distribuere de af mine
> programmer som er skrevet i SML ville det da også give problemer hvis
> du skulle oversætte dem på din source baserede distro. Du skulle jo
> først ud og finde en oversætter til dem og der efter konfigurere dem.

Det giver ikke så mange problemer som du tror, *hvis* der findes en SML
compiler der kan downloades og bruges uden de komplikationer som Kylix
giver. Specielt hvis der er tale om en Open Source compiler, så vil min
package manager sørge for resten. Som et eksempel, så var der et af mine
programmer der var skrevet i Objective-Caml. Da jeg bad installeren om
at hente den, blev den tilhørende Objective-Caml compiler hentet,
compilet og installeret først.

Den slags kan *ikke* gøres automatisk med Kylix (i hvert fald ikke sidst
jeg prøvede). Derfor skal jeg igennem en bunke manuelle skridt for at
installere programmet. Det er den slags jeg omtaler som
"komplikationer". Det er stadig muligt at gøre det, men en del af
automatikken bliver fjernet. Det *kan* være nok til at jeg ikke gider
gøre mere ved det.

--
PeKaJe

Everything you read in newspapers is absolutely true, except for that rare
story of which you happen to have first-hand knowledge. -- Erwin Knoll

---

Peter Jensen <jdogh001@sneakemail.com> writes:

> Martin Schultz wrote:
>
> >> Alle den slags overvejelser skal man gøre før man beslutter sig på en
> >> bestemt udviklingsplatform. Valget er op til udvikleren, men det skal
> >> være et *informeret* valg.
> >
> > Tjoo men hvis jeg for eksempel valgte at distribuere de af mine
> > programmer som er skrevet i SML ville det da også give problemer hvis
> > du skulle oversætte dem på din source baserede distro. Du skulle jo
> > først ud og finde en oversætter til dem og der efter konfigurere dem.
>
> Det giver ikke så mange problemer som du tror, *hvis* der findes en SML
> compiler der kan downloades og bruges uden de komplikationer som Kylix
> giver. Specielt hvis der er tale om en Open Source compiler, så vil min
> package manager sørge for resten. Som et eksempel, så var der et af mine
> programmer der var skrevet i Objective-Caml. Da jeg bad installeren om
> at hente den, blev den tilhørende Objective-Caml compiler hentet,
> compilet og installeret først.
Ok fint. HVad med java? Der skulle jeg i min gentoo installation igennem
en masse manuelle skridt. Det kan da ikke være slemmere end med kylix.


Martin

--
Besøg http://adsltips.crunzh.com for guider
til ADSL og opsætning af CISCO router.

---

Martin Schultz wrote:

> Ok fint. HVad med java? Der skulle jeg i min gentoo installation
> igennem en masse manuelle skridt. Det kan da ikke være slemmere end
> med kylix.

Java? Der oplevede jeg da ingen manuelle skridt. Hvornår var det, og
hvilken Java installerede du?

--
PeKaJe

Time sharing: The use of many people by the computer.

---

Peter Jensen <jdogh001@sneakemail.com> writes:

> Martin Schultz wrote:
>
> > Ok fint. HVad med java? Der skulle jeg i min gentoo installation
> > igennem en masse manuelle skridt. Det kan da ikke være slemmere end
> > med kylix.
>
> Java? Der oplevede jeg da ingen manuelle skridt. Hvornår var det, og
> hvilken Java installerede du?

hmm det var vel omkring et sted mellem 1 og 1½ år siden. Det var suns java
jeg installerede.


Martin
--
Besøg http://adsltips.crunzh.com for guider
til ADSL og opsætning af CISCO router.

---

Martin Schultz wrote:

>>> Ok fint. HVad med java? Der skulle jeg i min gentoo installation
>>> igennem en masse manuelle skridt. Det kan da ikke være slemmere end
>>> med kylix.
>>
>> Java? Der oplevede jeg da ingen manuelle skridt. Hvornår var det, og
>> hvilken Java installerede du?
>
> hmm det var vel omkring et sted mellem 1 og 1½ år siden. Det var suns
> java jeg installerede.

Det forklarer lidt. Jeg bruger blackdown Java. Den kan downloades uden
de store problemer, imens man skal naviger lidt rundt for at finde Suns
Java. I det mindste findes der alternativer til den restriktive Java,
mens Borland er den eneste compilerleverandør til Kylix programmer.

--
PeKaJe

Life exists for no known purpose.

---

Henrik Lynggaard wrote:

> Jeg forsøger i øjeblikket at bruge c++ under linux, og det er
> umiddelbart sværere end jeg troede. Jeg kommer fra java verdenen og
> har ellers kun lært lidt c++ til arbejdsbrug på windows, så jeg er
> lidt forvent hvad angår IDE's og ligende.

På nær til at designe den grafiske brugergrænseflade, så er en IDE
egentligt lidt overflødig. Vim eller Emacs kan gøre hvad du skal bruge,
forudsat at du bruger lidt tid på at sætte dig ind i editorens
finurligheder. De kan spare *meget* tid senere hen ...

> Jeg har derfor søgt lidt på nettet, og da jeg kører gnome har jeg
> installeret anjuta+glade samt diverse lib**mm bilioteker.

Kender ikke lige programmet, da det ser noget Gnome relateret ud.

> Men selv når jeg opretter et simpelt terminal/konsol (tomt?) c++
> project i anjuta, så bliver jeg fuldstændigt overvældet af mængden af
> filer den laver. Den laver 37 filer for et simpelt projekt,

Er det så med de filer som laves under compilering?

> og jeg havde forventet max 3.

Så er det enten et *meget* simpelt projekt, eller et hvor du selv
skriver den tilhørende Makefile. Det er med andre ord ret unormalt, selv
for et Hello World program.

> Er der nogen her som kan fortælle mig hvad alle de filer skal gøre
> godt for og hvordan de bruges?

Man kan jo prøve ...

> Jeg havde forventet noget i retning af:
>
> src/main.cpp // main c++ filen
> <projectnavn>.project // projectfilen til IDE'et
> <buildfil> // en fil ala et ant build script til at bygge projektet
> udenom IDE'et.
>
> Men I stedet har jeg fået:
>
> // disse filer er vist bare tekstfiler som det er meningen jeg skal
> skrive/udfylde
> AUTHORS
> ChangeLog
> NEWS
> README
> TODO

Disse filer er krævet af GNU coding standard. Du kan lige så godt vænne
dig til at skrive standardiseret og veldokumenteret, hvis dit projekt
nogensinde skal bruges. Læs mere her:

http://www.gnu.org/prep/standards_toc.html

> // næsten de(n) projektfiler jeg regnede med. Det ene er åbenbart en
> backup hvilket er ok
> // men hvorfor er der ikke backup af den anden.
>
> VideoStore.prj
> VideoStore.prj.bak
> VideoStore.pws

De er vist relateret til IDE'en.

> // Den main fil jeg havde forventet. Plus noget andet fyld.
> src/Makefile

Det er build filen. Den fortæller 'make' hvad den skal gøre. Den er
genereret af './configure' ud fra en mere logisk opbygget 'Makefile.in'.

> src/Makefile.am

Dette er den eneste Makefile du skal røre. Den fortæller 'automake'
hvordan 'Makefile.in' skal laves. I den skal angives hvilke source filer
der skal compileres, samt hvad programmet skal hedde.

> src/Makefile.in

Er forklaret.

> src/main.cc

Og den kender du jo godt ...

> // Nu begynder det at gå galt for mig, Hvad er er alle disse filer ?
> // - hvad gør de ?, hvorfor er de nødvendige ?
>
> COPYING -> /usr/share/automake-1.4/COPYING

Indeholder betingelserne for brug af projektet. Jeg vil gætte på at den
linker til en kopi af GPL-2.

> INSTALL -> /usr/share/automake-1.4/INSTALL

Fortæller hvordan man installerer programmet. I standardudgaven
henvender den sig mest til folk der aldrig har installeret GNU
kompatibelt software før.

> install-sh -> /usr/share/automake-1.4/install-sh
> missing -> /usr/share/automake-1.4/missing
> mkinstalldirs -> /usr/share/automake-1.4/mkinstalldirs

Lidt hjælpeprogrammer der også er lavet af 'automake'. Jeg mener at
'install-sh' erstatter '/bin/install' på de systemer der ikke har dette
program. Det sikrer at dit program er en smule mere portabelt.

> Makefile
> Makefile.am
> Makefile.in

Som før, bare gældende for hele dit projekt. Normalt er der jo andet end
src underbiblioteket der skal berøres.

> acconfig.h
> acinclude.m4
> aclocal.m4
> autogen.sh
> config.cache
> config.guess
> config.h
> config.h.in
> config.log
> config.status
> config.sub
> configure

Automatisk genereret af enten 'aclocal', 'autoconf', 'autoheader',
'automake' eller './configure'.

> configure.in

Bruges på samme måde som Makefile.in til at generere './configure'. Jeg
savner lidt den mere overordnede 'configure.ac', som er mere
"menneskelig". Den bliver tilsyneladende ikke brugt af den mekanisme der
er indbygget i IDE'en.

> conftest
> conftest.c
> conftest.o

Jeg vil gætte på at det er et midlertidigt program der er blevet lavet
for at teste en eller anden konfiguration. Prøv at kigge i .c filen og
sammelign med hvad './configure' siger den laver.

> include
> libtool
> ltmain.sh
> setup-gettext

Lidt mere autogenereret stof vil jeg gætte på ...

> stamp-h
> stamp-h.in

Jeg vil tro at det er en timestamp for en af de genererede headerfiler.
Prøv at læse dem.

> Umiddelbart virker alle disse filer en smule lavteknisk, og ikke særligt
> strømlinet.

De fleste af dem var aldrig beregnet på at mennesker skulle læse dem, så
det kan jeg godt forstå ...

> Håber der er nogen som kan få mig til at se lyset, så det hele virker
> mere logisk.

Jeg vil anbefale at du lærer en smule om autotoolset. Der er en
udemærket tutorial på: http://autotoolset.sf.net

Det skal dog lige siges at deres Hello World program ikke kan
"autoconfiskeres" med version 1.4 af programmerne. Du har formentligt
nyere installeret. Hvis f.eks. 'automake-1.7' findes, så kan du få den
til at blive brugt ved at have environment variablen 'WANT_AUTOMAKE' sat
til "1.7".

Hvis du ikke skal lave GUI programmer fra starten af, så er det nok en
god ide at glemme IDE'en for nu. Fokuser på at lære hvordan simple
projekter opbygges fra grunden af i Linux. Alt det andet er lettere at
bygge på bagefter.

Have fun ...

--
PeKaJe

pain, n.:
   One thing, at least it proves that you're alive!

---

Peter Jensen wrote:
> Henrik Lynggaard wrote:
>
>>og jeg havde forventet max 3.
>
>
> Så er det enten et *meget* simpelt projekt, eller et hvor du selv
> skriver den tilhørende Makefile. Det er med andre ord ret unormalt, selv
> for et Hello World program.

Det behøver absolut ikke være særligt simpelt. Nu kommer jeg fra java
verdenen og der vil jeg kunne klare selv forholdsvis store projekter med
ca 3 filer

ant kan jeg 1 en fil lave følgende:

- hente det nyeste fra versionstyringssystemet
- compile projektet
- Generere kode dokumentationen.
- Pakke filerne ned i distribuerbare pakker.
- deploye applicationen til f.eks. en applications server.
- Køre unit tests og få en test rapport.

Alt sammen i et script som er kortere end makeFile,in. Så enten ligger
der meget funktionalitet i filerne som jeg ikke kender eller værdsætter
endnu.

Dertil kommer en properties fil til ant scriptet og den første java fil.

hvilket giver 3 filer til at starte med

>>AUTHORS
>>ChangeLog
>>NEWS
>>README
>>TODO
>
>
> Disse filer er krævet af GNU coding standard. Du kan lige så godt vænne
> dig til at skrive standardiseret og veldokumenteret, hvis dit projekt
> nogensinde skal bruges. Læs mere her:
>
> http://www.gnu.org/prep/standards_toc.html

Tak for linket, det vil jeg læse igennem når jeg får lidt tid. Jeg er
vant til at dokumentere mine projekter, jeg er bare ikke vant til at
compile toolet presser den struktur ned over hovedet på mig.


>>// Den main fil jeg havde forventet. Plus noget andet fyld.
>>src/Makefile
>
> Det er build filen. Den fortæller 'make' hvad den skal gøre. Den er
> genereret af './configure' ud fra en mere logisk opbygget 'Makefile.in'.
>
>>src/Makefile.am
>
>
> Dette er den eneste Makefile du skal røre. Den fortæller 'automake'
> hvordan 'Makefile.in' skal laves. I den skal angives hvilke source filer
> der skal compileres, samt hvad programmet skal hedde.

Men hvorfor er der 6 build filer i stedet for bare 1 ?




>>conftest
>>conftest.c
>>conftest.o
>
>
> Jeg vil gætte på at det er et midlertidigt program der er blevet lavet
> for at teste en eller anden konfiguration. Prøv at kigge i .c filen og
> sammelign med hvad './configure' siger den laver.

conftest.c indeholder:

static int dummy;

Har lidt svært ved at finde funktionaliteten i dette

> Jeg vil anbefale at du lærer en smule om autotoolset. Der er en
> udemærket tutorial på: http://autotoolset.sf.net

Den vil jeg kikke på.

> Hvis du ikke skal lave GUI programmer fra starten af, så er det nok en
> god ide at glemme IDE'en for nu. Fokuser på at lære hvordan simple
> projekter opbygges fra grunden af i Linux. Alt det andet er lettere at
> bygge på bagefter.

Det er jo netop det jeg forsøger at gøre ved at ikke starte med et gui
projekt eller noget i den stil.
I stedet valgte jeg et "tomt" projekt (Generic/Terminal), fordi det
netop kun burde give mig de absolut nødvendige filer.

mvh
henrik

---

On Thu, 12 Jun 2003 22:34:33 +0200, Henrik Lynggaard
<henrik@lynggaard.org> wrote:

> Håber der er nogen som kan få mig til at se lyset, så det hele
> virker mere logisk.

I forbindelse med makefiles, autoconf og automake kunne du læse
<http://www.murrayc.com/learning/linux/automake/automake.shtml> og
nogle af de artikler der henvises til i dokumentet.

Se om du kan se *Lyset* ;)

--
Michael Wojciechowski

One must suffer before enlightenment.

---

Henrik Lynggaard wrote:

> Jeg forsøger i øjeblikket at bruge c++ under linux, og det er
> umiddelbart sværere
> end jeg troede. Jeg kommer fra java verdenen og har ellers kun lært lidt
> c++ til
> arbejdsbrug på windows, så jeg er lidt forvent hvad angår IDE's og ligende.
Hvad behøver man andet end xemacs, g++ og make

> Jeg har derfor søgt lidt på nettet, og da jeg kører gnome har jeg
> installeret anjuta+glade
> samt diverse lib**mm bilioteker.
Det skulle efter sigende være ganske godt, men lidt omfattende

> Men selv når jeg opretter et simpelt terminal/konsol (tomt?) c++ project
> i anjuta, så bliver jeg
> fuldstændigt overvældet af mængden af filer den laver. Den laver 37
> filer for et simpelt projekt,
> og jeg havde forventet max 3.
Den laver filer til automake og autoconf. Den fil der indeholder dine
project filer er sansynligvis "Makefile.am". Når du bruger disse er der
en del filer den kræver for at opfylder en streamlinet automatik. Anjuta
hjælper dig med at vedligeholde disse.

Hvis du senere finder på noget andet kan du jo "bare" hive dine source
filer ud, og lave en anden opbygning (håndskrevet make eller cmake kan
også anbefales)

Jeg har faktisk ikke brugt Anjuta fordi den laver automake, og det er
ikke godt til rene kommercielle programmer (automake/conf er ren GLP),
og dem laver jeg også nu og da.

> Er der nogen her som kan fortælle mig hvad alle de filer skal gøre godt
> for og hvordan de bruges?
Hermed.

> Jeg havde forventet noget i retning af:
>
> src/main.cpp // main c++ filen
> <projectnavn>.project // projectfilen til IDE'et
> <buildfil> // en fil ala et ant build script til at bygge projektet
> udenom IDE'et.
Jeg forstår dig, men jeg har endu ikke fundet et værktøj på *nix der er
så simpelt, som du skitserer. Men tilgængæld kan du let porte din "hello
world" til en hvilken som helst *nix platform

>
> Umiddelbart virker alle disse filer en smule lavteknisk, og ikke særligt
> strømlinet.
Der er lidt overvælende, men der skam fornuft i det (tro mig), men det
er automake/conf dokumentation der skal give dig det detalierede overblik.

> Håber der er nogen som kan få mig til at se lyset, så det hele virker
> mere logisk.
Håber det hjalp lidt

/BL

---

Bo Lorentsen wrote:

> Jeg har faktisk ikke brugt Anjuta fordi den laver automake, og det er
> ikke godt til rene kommercielle programmer (automake/conf er ren GLP),
> og dem laver jeg også nu og da.

Bt! Wrong. Her er et par citater fra de relevante info-sider:

---
Distributing `configure' Scripts
================================

What are the restrictions on distributing `configure'
scripts that Autoconf generates? How does that affect my
programs that use them?

There are no restrictions on how the configuration scripts that
Autoconf produces may be distributed or used. In Autoconf version 1,
they were covered by the GNU General Public License. We still encourage
software authors to distribute their work under terms like those of the
GPL, but doing so is not required to use Autoconf.

Of the other files that might be used with `configure',
`config.h.in' is under whatever copyright you use for your
`configure.ac'. `config.sub' and `config.guess' have an exception to
the GPL when they are used with an Autoconf-generated `configure'
script, which permits you to distribute them under the same terms as
the rest of your package. `install-sh' is from the X Consortium and is
not copyrighted.
---

Og

---
Distributing `Makefile.in's
***************************

Automake places no restrictions on the distribution of the resulting
`Makefile.in's. We still encourage software authors to distribute
their work under terms like those of the GPL, but doing so is not
required to use Automake.

Some of the files that can be automatically installed via the
`--add-missing' switch do fall under the GPL. However, these also have
a special exception allowing you to distribute them with your package,
regardless of the licensing you choose.
---

Altså må de autoconfiskerede filer distribueres under hvilken som helst
licens du ønsker. Du risikerer dermed ikke at noget GPL materiale bliver
en nødvendig del af dit projekt, sådan som det var gældende for Autoconf
version 1. Der skulle derfor ikke være nogle problemer med at lave et
"kommercielt" (eller i det hele taget non-GPL) program.

--
PeKaJe

Message from Our Sponsor on ttyTV at 13:58 ...

---

Peter Jensen wrote:
>>Jeg har faktisk ikke brugt Anjuta fordi den laver automake, og det er
>>ikke godt til rene kommercielle programmer (automake/conf er ren GLP),
>>og dem laver jeg også nu og da.
>
>
> Bt! Wrong. Her er et par citater fra de relevante info-sider:
Det var da en herlig ting. Det er da rart man kan tage fejl en gang imellem.

> There are no restrictions on how the configuration scripts that
> Autoconf produces may be distributed or used. In Autoconf version 1,
> they were covered by the GNU General Public License. We still encourage
> software authors to distribute their work under terms like those of the
> GPL, but doing so is not required to use Autoconf.
Hmm, så det er mere som GCC end som readline ...

> Altså må de autoconfiskerede filer distribueres under hvilken som helst
> licens du ønsker. Du risikerer dermed ikke at noget GPL materiale bliver
> en nødvendig del af dit projekt, sådan som det var gældende for Autoconf
> version 1. Der skulle derfor ikke være nogle problemer med at lave et
> "kommercielt" (eller i det hele taget non-GPL) program.
Mange tak, jeg vil straks genoverveje min brug af automake ...

/BL

---

Bo Lorentsen wrote:
> Henrik Lynggaard wrote:
>
>> Jeg forsøger i øjeblikket at bruge c++ under linux, og det er
>> umiddelbart sværere
>> end jeg troede. Jeg kommer fra java verdenen og har ellers kun lært
>> lidt c++ til
>> arbejdsbrug på windows, så jeg er lidt forvent hvad angår IDE's og
>> ligende.
>
> Hvad behøver man andet end xemacs, g++ og make

Kender ikke xemacs, men giver den kombination:

* syntax farvning ah alle filer.
* Auto complete,også af egen skrevet kode og ikke bare standard libs
* Contekt hjælp, der kan slå direkte op i den relevante API
dokumentation. Står Jeg med curseren på en std::string og trykker F1, så
skal den slå op på siden om std:string.
* Integreret debugger, hvor man følger med i source når man single
stepper sig gennem programmet

Dette må være absolut! laveste fællesnævner for et udviklingsmiljø, og
så er jeg ikke engang begyndt at tale om nice-to-have features.


>> Jeg havde forventet noget i retning af:
>>
>> src/main.cpp // main c++ filen
>> <projectnavn>.project // projectfilen til IDE'et
>> <buildfil> // en fil ala et ant build script til at bygge projektet
>> udenom IDE'et.
>
> Jeg forstår dig, men jeg har endu ikke fundet et værktøj på *nix der er
> så simpelt, som du skitserer. Men tilgængæld kan du let porte din "hello
> world" til en hvilken som helst *nix platform

I java kan man, og det er ikke begrænset til *nix systemer

mvh
henrik

---

Henrik Lynggaard wrote:
> Kender ikke xemacs, men giver den kombination
>
> * syntax farvning ah alle filer.
Yeps, og flere forskellige indent typer, og rigtig mange forskellige sprog.

> * Auto complete,også af egen skrevet kode og ikke bare standard libs
Jeg tror svaret her ligger i xemacs binding til ctags eller etags, som
kan parse dine source filer og give en form for index fil, som xemacs
kan bruge. Jeg har dog aldrig set autocompletion i xemacs, men hvorfor
ikke Hvis alt går galt kan du jo "bare" kode xemacs macroer ... i lisp.

> * Contekt hjælp, der kan slå direkte op i den relevante API
> dokumentation. Står Jeg med curseren på en std::string og trykker F1, så
> skal den slå op på siden om std:string.
Context hjælp kræver hjælpefiler, og de er ikke så komplete som i fks.
borland's IDE'er. Men det har Per A. allerede nævnt.

I OS verdenen er der ikke mange der føler sig kaldet til at samle alt
den information der findes (for det findes), i ordenlige hjælpe filer.
Vi har værktøjerne (info fks.), men det kræver jo også lidt kedeligt
arbejde

> * Integreret debugger, hvor man følger med i source når man single
> stepper sig gennem programmet
Det er også muligt.

> Dette må være absolut! laveste fællesnævner for et udviklingsmiljø, og
> så er jeg ikke engang begyndt at tale om nice-to-have features.
Jeg er med på hvad du mener, og Anjuta er nok mere et IDE som virker som
windows IDE'er "out of the box". Fordelen ved xemacs er den tilpassings
evne, og den mange mulighedder (rigtig rigtig mange !!!) til
opsætninger. Der er af og til nogle der kalder (x)emacs et OS og ikke
bare en editor, og andre bruger vi i protest

Men, du kan ikke bare installerer en xemacs, og forvente at alt er som i
VC++ eller Borland, det er *nix verdenen simpelthen for anderledes til.

/BL

---

Henrik Lynggaard <henrik@lynggaard.org> writes:

> Kender ikke xemacs, men giver den kombination:

Jeg svarer for Emacs, men XEmacs er normalt det samme.

> * syntax farvning ah alle filer.

Ja.

> * Auto complete,også af egen skrevet kode og ikke bare standard libs

Der er et virvar af completion fasciliteter. Jeg tror også der er den
du søger, men den kan være svær at finde.

> * Contekt hjælp, der kan slå direkte op i den relevante API
> dokumentation. Står Jeg med curseren på en std::string og trykker F1,
> så skal den slå op på siden om std:string.

Der er en generel context sensitive help facilitet, jeg vil tro der
også findes en hjælpefil til C++. Men igen, den er ikke installeret
"out of the box".

> * Integreret debugger, hvor man følger med i source når man single
> stepper sig gennem programmet

Ja.

---

Bo Lorentsen <bl@nospam.lue.dk> writes:

> Men, du kan ikke bare installerer en xemacs, og forvente at alt er som
> i VC++ eller Borland, det er *nix verdenen simpelthen for anderledes
> til.

Både GNU Emacs og XEmacs findes til Microsoft Windows. Det er nok
rigtigere at sige "Det er Emacs simpelthen for anderledes til".

Emacs er et rigtig stærkt værktøj, blandt andet fordi det gør mange
ting meget anderledes end andre programmer der løser nogle af de samme
opgaver. Derfor kræver det også en del tilvænning før man eventuelt
bliver glad for at bruge Emacs.

--
Jacob - www.bunk.cc
Where are the calculations that go with a calculated risk?