ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Programmierung > AmiDevCpp | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
1 -2- 3 4 | [ - Beitrag schreiben - ] |
11.10.2005, 14:32 Uhr TerAtoM Posts: 1230 Nutzer |
@Kaesebroetchen: Hallo, es hat sich jetzt eigentlich alles aufgelösst. Ich habe das ganze nämlich auf einem ENGLISCHEN WinXP installiert. Dort hat das Standartverzeichniss den Namen "Program Files" (im Deutschen wäre es ja "Programme"). Das hat wohl zu den ganzen schwierigkeiten geführt. Ich habe nun wieder ein neu installiertes WinXP (Englisch) genommen und den Standartpfad auf "Programme" geändert. Dann wieder AmiDevCPP (übrigens immer die neue v0.4) installiert und nun kann man alles einwandfrei Compilieren (zumindest die Basissachen die sich Automatisch anlegen). Vielleicht sollte das in einem kleinen ReadMe.txt File erwähnt werden das keine Leerzeichen im Installationspfad sein dürfen, bzw. das man bei einer Englischen Windowsversion auf das "Program File" nicht installieren kann/sollte wenn man auch die C++ sparte abdecken möchte. Ist zwar ein "Dummer" Fehler aber ich habe ihn begangen und das obwohl ich von dem "Lerrzeichen im Pfad" Problem wusste. CU TerA -- Bild: http://img.photobucket.com/albums/v283/TerAtoM/TeratomLogo.jpg A4K 604e/233MHz 060/50MHz 146MB CV64_3D+SD & CVPPC Band: http://www.TERATOM.de - Amiga: http://www.AmigaProject.de.vu Privat: http://www.TerAmigA.de.vu - Profession: http://www.Xavo.de [ - Antworten - Zitieren - Direktlink - ] |
11.10.2005, 14:37 Uhr Holger Posts: 8116 Nutzer |
Zitat:Was hat das mit der Frage noch der korrekten Anwendung der #include Anweisung zu tun? Das klingt doch alles nur nach herumpfuschen an den Symptomen-zuerst include falsch benutzen und dann mit links alles unnötig komplizierter machen als nötig. Der Präprozessor besitzt mit #ifdef usw. Konstrukte, die genau dafür gedacht sind, ein Herumdoktorn an der Verzeichnisstruktur des Projekts ist vollkommen unnötig. Zitat:Resourcenverschwendung-wenn doch wenigsten auf EINER Plattform das Ganze stabil laufen würde... Außerdem werden configure-Skripte sowieso automatisch generiert-nur wenn niemand auf den verschiedenen Plattformen überhaupt mal einen Testlauf durchführt, ist es komplett sinnlos. Theoretische Plattformunabhängigkeit ist keine. Zitat:HÄ? Der compiler für ein bestimmtes target kennt bereits die Aufruf-Konventionen--im C-Source muß absolut nichts angepaßt werden. Aros ist eh nur auf C-Source-Ebene kompatibel-ein Herumpfuschen an plattformspezifischen Eigenheiten sollte ja genau aus diesem Grund überflüssig sein. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
11.10.2005, 16:23 Uhr Kaesebroetchen Posts: 643 Nutzer |
@TerAtoM: Das ist gut. Ich werde dann erst mal einen Hinweis auf die Homepage legen. -- http://amidevcpp.kilu.de/ [ - Antworten - Zitieren - Direktlink - ] |
11.10.2005, 18:44 Uhr bernd_roesch Posts: 364 [Benutzer gesperrt] |
>Das klingt doch alles nur nach herumpfuschen an den Symptomen-zuerst include falsch benutzen wenn du linux hast mach mal mit deren ihrem buildsystem (configure und make aufrufen) ein testprog. Ich denke du kannst auch ein file im selben dir wie das aufrufende mit <> einbinden.von daher wenn nix meckert macht man es automatisch mal aus versehen falsch es ist nicht nur aros.zu meiner aztec C zeit wenn ich als mal sourcen runterludt und kompilieren wollte, fand er auch nie die .h files und nix ging.Ich habe das auch nie gewusst,dass mann dann einfach " " setzt. aber dank moderner technik in VC braucht man heute auch nimmer seitenlange man pages zu wälzen.einfach help über include gedrückt und schon weis man was sache ist.C ist nunmal zu verworren als das man da was schnell fehlerfrei hinkriegt das ganze include zeugs hat mich immer abgenervt irgend nen fremden C source zu probieren egal was,aber einfach einladen kompilieren und geht,sowas hab ich bei C nie erlebt.selbst den winuae kann ich nun durch geänderte config files von den neueren VC nicht einfach so reinladen. gegenüber früher aztec C kam ich mit amidev doch recht schnell zu nem ziel auf 68k kompilieren zu können und Hilfe bei problemen bekam ich von Georg und anderen auch immer schnell. in amidev fehlt mir nur noch der kprintf,wenn ich in main.c reinschreibe krpintf() { } kann ich das exe erstellen.nur kprintf ausgaben wollte ich schon auch machen können >HÄ? >Der compiler für ein bestimmtes target kennt bereits die Aufruf-Konventionen--im C-Source muß absolut nichts angepaßt werden. wenn man die parameter per register übergeben will ohne die includes oder stubs zu ändern muss man ja festlegen wo in welches register der architektur der par reinkommt.dazu muss man die gcc asm befehle nutzen wo den par der architektur zuordnen. Auch für nen aros arm port sind sourcen da.schau dir doch mal amiga libs oder MUI Klassen an wo es für 68k MOS OS4 native gibt.voll mit #ifdef.unter aros ist das nicht nötig und es geht unter 68k PPC X86 arm 64 bit oder sonstwas. Der Grundstock für platformunabhängig ist da. Man könnte sich zwar den ganzen heckmeck sparen,und nur über stack aufrufen,denn heutige CPU's sind eh schnell genug aber bei MOS wurde auch gesagt es nutzt die Registerübergabe die es verhindert auf X86 portierbar zu sein. Aros unterstüzt sowohl stackpars als auch registerpars.das es registerpars hat,macht es das als OS3.1 ersatz reinzubauen einfacher. z.b für 68k gemäss OS3.1 konventionen sehen die defines so aus. #define __AROS_LHA(type,name,reg) register type name __asm(reg) #define __AROS_LPA(type,name,reg) register type __asm(reg) #define __AROS_LCA(type,name,reg) name #define __AROS_LDA(type,name,reg) register type __asm(reg) #define __AROS_UFHA(type,name,reg) register type name __asm(reg) #define __AROS_UFPA(type,name,reg) register type __asm(reg) #define __AROS_UFCA(type,name,reg) name #define __AROS_UFDA(type,name,reg) register type __asm(reg) für X86 so #define __AROS_LHA(type,name,reg) type name #define __AROS_LPA(type,name,reg) type #define __AROS_LCA(type,name,reg) name #define __AROS_LDA(type,name,reg) type #define __AROS_UFHA(type,name,reg) type name #define __AROS_UFPA(type,name,reg) type #define __AROS_UFCA(type,name,reg) name #define __AROS_UFDA(type,name,reg) type #define __AROS_LHAQUAD(type,name,reg1,reg2) type name #define __AROS_LPAQUAD(type,name,reg1,reg2) type #define __AROS_LCAQUAD(type,name,reg1,reg2) name >Resourcenverschwendung-wenn doch wenigsten auf EINER Plattform das Ganze stabil laufen würde... Tja bei Linux wurde die Platformunabhängigkeit genauso eingeführt.nur fanden sich halt mehr wo coden. vieleicht gab es da auch keine weiteren Anbieter wo Unix auf X86 bringen wollten,so halfen eben alle bei Linux mit Ich möchte AROS mal für 68k als OS3.1 ersatz nutzbar machen.zumindest hat man den Vorteil wenn man auf die alten OS funcs zurückgreifen kann immer was lauffähiges zu haben. erst wird die layerlib ersetzt weil die bei P96 arg lahm ist für opaque fenster move. dadurch das AROS opensource ist kann man es wenigstens verbessern.man ist nicht von nem Hersteller abhängig [ - Antworten - Zitieren - Direktlink - ] |
11.10.2005, 19:51 Uhr Kaesebroetchen Posts: 643 Nutzer |
Zitat: Klingt Interessant ! Wäre das binärkompatibel zum AmigaOS ? -- http://amidevcpp.kilu.de/ [ - Antworten - Zitieren - Direktlink - ] |
11.10.2005, 20:50 Uhr Holger Posts: 8116 Nutzer |
Zitat:Niemand hat gesagt, daß C einfach ist. Ich programmiere auch bevorzugt in anderen Programmiersprachen, trotzdem kenne ich die richtige Anwendung von #include und vor allem würde ich mich erst mal mit der Materie ausreichend beschäftigen, bevor ich mir ein Projekt in der Größenordnung eines ganzen Betriebssystems auflade. Aber Aros-Entwickler ticken ja demnach etwas anders... Zitat:Tja, kprintf dient der Ausgabe aus dem Kernel und ist deshalb bei der normalen Anwendungserstellung natürlich nicht vorhanden. Dazu muß man die Software an eine spezielle Bibliothek für Kernel-Entwicklung linken. Konnte Dir das keiner der Aros-Entwickler sagen? Eine entsprechende Bibliothek müßte ja im Aros-Source enthalten sein, wenn dieses ein komplettes Betriebssystem werden will (und kprintf selber verwendet). Zitat: Vollkommener Quatsch. Nochmal: Aros beinhaltet keine Kompatiblität zu 68k-Anwendungen, benutzt deshalb das ABI der Zielplattform. Und genau dieses wird vom Compiler automatisch verwendet, wenn man eine Zielplattform auswählt. Wenn das ABI der Zielplattform Registerübergabe verwendet, wie z.B. bei den üblichen ppc-ABI, dann benutzt auch der Compiler Registerübergabe für die Funktionsaufrufe, sobald man für diese Plattform übersetzt. Dazu muß man keine Stunts mit dem Präprozessor machen. Einzige Ausnahme ist eben 68k, wenn man Binärkompatibel mit dem Amiga sein will. Für die x86, IA64, ppc, alpha oder arm Versionen ist das aber unwichtig. Zitat:Linux hat keine neuen ABIs eingeführt. Zitat:Du meinst, außer zum Beispiel BSD? Zitat: Das ist ja prinzipiell eine gute Idee, aber ohne daß einer der Kernentwickler gleiche Ambitionen entwickelt, wird das nie etwas werden. Die halbherzigen Aussagen bezüglich 68k-Kompatiblität helfen Dir da nicht weiter. Du bist so ja schon mehr mit dem Überarbeiten der Dinge beschäftigt, die theoretisch eigentlich schon funktionieren sollten. Vom Fertigstellen eines solchen Projekts wollen wir gar nicht erst reden... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
11.10.2005, 20:55 Uhr Holger Posts: 8116 Nutzer |
Zitat: In der Theorie ja. Aber genausogut könnte man für dieses eine Feature eine re-Implementierung von Picasso96 machen (darauf läufts ja sowieso hinaus) und sich die Mühe mit dem 68k-Port von Aros sparen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
12.10.2005, 09:37 Uhr gni Posts: 1106 Nutzer |
Zitat:Was, es gibt tatächlich Alternativen zu Linux!? SCNR. [ - Antworten - Zitieren - Direktlink - ] |
12.10.2005, 10:41 Uhr bernd_roesch Posts: 364 [Benutzer gesperrt] |
>Vollkommener Quatsch. >Nochmal: Aros beinhaltet keine Kompatiblität zu 68k-Anwendungen, benutzt deshalb das ABI der Zielplattform. Hast dir aros noch nie angesehen und dann weist du das schon.. Mir hat Georg gerade die aros diskfont library geschickt wo er vor 3 Jahren zu testzwecken für uae erstellte Das zeigt es geht ohne #ifdef orgien ansonsten hat es ca 5 Std (4 E-Mails wenn man das warten auf Mail pausen abzieht) gebraucht um aros ohne Linux als Host zu compilieren.normalerweise ist aros buildsystem dazu ausgelegt über das configure script unter Linux alles zu ermitteln und manche files (z.b lidefs.h) automatisch zu erstellen.deshalb braucht man Linux um es zu kompilieren Aber es ist auch so gut durchdacht,denn wenn man machine.h (wo ich von Georg's diskfont lib habe)von Hand anpasst,das libdefs_68k_uae.h (_68k_uae.h ist ein file wo nicht in aros vorkommt,und einmal pro amigaoslib im dir sein muss) von Hand erstellt,kann man die lib ohne source Änderung auf jedem beliebigen system compilieren. Da MOS auch AROS nutzt gingen die wohl den selben Weg nur wie es geht haben die nicht verraten oder das machine.h für aros lib funcs hostet on MOS releast. Im prinzip ist das was ich machen will ähnlich MOS.MOS hatte allerdings schon (super)layerslib und gfx libs von CGX her. BeiBei MOS ists die gadtoolslib und (teile oder ganz weis ich nicht) intuition.library Da das einbinden der libdefs auch über ein define geht,kann man jedes beliebige file einbinden ohne den source zu ändern.die endung _68k_uae.h #include LC_LIBDEFS_FILE im machine.h definiere ich dann #define LC_LIBDEFS_FILE "libdefs_68k_uae.h" somit nimmt aros kernel libsource dieses file. so sieht das für die layers lib 68k aus #ifndef _LAYERS_LIBDEFS_H #define _LAYERS_LIBDEFS_H #define GM_UNIQUENAME(n) Layers_ ## n #define LIBBASE LayersBase #define LIBBASETYPE struct LayersBase #define LIBBASETYPEPTR struct LayersBase * #define MOD_NAME_STRING "layers.library" #define VERSION_NUMBER 41 #define MAJOR_VERSION 41 #define REVISION_NUMBER 0 #define MINOR_VERSION 0 #define VERSION_STRING "$VER: layers.library 41.0 (10.10.2005) rn" #define COPYRIGHT_STRING "" #define LIBEND GM_UNIQUENAME(End) #define LIBFUNCTABLE GM_UNIQUENAME(FuncTable) #define RESIDENTPRI 60 #define RESIDENTFLAGS RTF_AUTOINIT|RTF_COLDSTART #include "layers_intern.h" #define GM_SYSBASE_FIELD(lh) (((LIBBASETYPEPTR)lh)->lb_SysBase) #define GM_SEGLIST_FIELD(lh) (((LIBBASETYPEPTR)lh)->lb_SegList) #endif * _LAYERS_LIBDEFS_H * Das hat mich positiv überrascht,ich dachte auch es ist änderung im Source nötig, so wie z.b ne lib von OS4 zu MOS portieren,dass dann dutzende #ifdefs notwendig sind für jeden Befehl.amigaos hat ca 500 befehle,da hätte ich dann auch keine lust zu Man kann die original aros sourcen nehmen und muss nix anpassen,von daher wenn die AROS Kernelentwickler keine ambition haben uae aros zu unterstützen,ists nicht schlimm. wie man im aros source sieht,ist aber die AROS layerslib noch nicht komplett,ausserdem kann es auch sein,dass strukturen anders sind(einträge vertauscht).deshalb wollt ich kprintf um debugausgaben zu haben. aber da die aros (oder besser amiga headerfiles wo platformunabhängig gemmacht wurden) eh nicht änderungen ausgesetzt sind,kann ich auch eigene headerfiles machen und kann trotzdem wenn die kernelentwickler was an layerslib upddaten direkt das file nutzen per setfunction ändert man dann die lib adresse auf den neuen code.Da weis ich auch noch nicht wie man die adresse einer funktion in C erhält.denn die adresse muss ich setfunction übergeben Falls in den nächsten Jahren OS4 oder MOS nicht mehr weiterentwicklet wird,und AROS sich weiterentwickelt besteht dann die selbe möglichkeit wie bei OS3.1 ersetzen nur eben PPC vieleicht kommt dadurch mal ne sourcecode Einheit zustande und weniger ifdefs >Tja, kprintf dient der Ausgabe aus dem Kernel und ist deshalb bei der normalen Anwendungserstellung natürlich nicht vorhanden. Dazu muß man die Software an eine woher hast du denn die Weisheit.du solltest dich mal wieder mit amigaos beschäftigen.es ist der Befehl den jeder C entwickler unter amiga OS braucht wo etwas weiterentwickeln will wo keinen modernen sourcelevel debugger hat (also ziemlich alle) der befehl gibt den text auf dem seriel device aus.Kann man mit sushi in ne shell umleiten. >Aber genausogut könnte man für dieses eine Feature eine re-Implementierung von Picasso96 machen (darauf läufts ja sowieso hinaus) und sich die Mühe mit dem 68k-Port von Aros sparen. nur der source für layer ist ja schonmal soweit da.Von 0 anfangen ist quatsch damit man amigaOS erweitern kann,nimmt man dann eben den source.z.b graphics lib source um alpha blending ins API zu integrieren oder intuition lib um schöneres fenster aussehen ohne patches zu erhalten. feelin ist ja auch opensource,vieleicht hat jemand Lust den feelin GUI look reinzubauen und man kann es mit dem feelin prefs prog einstellen somit lässt sich jedes amiga OS auch PPC(wenn es ne AROS hostet on PPC lib gibt) per aroscode erweitern [ - Antworten - Zitieren - Direktlink - ] |
12.10.2005, 11:32 Uhr Solar Posts: 3680 Nutzer |
Zitat: Bernd, dazu muß man sich AROS nicht "ansehen", das ist, was vom AROS-Team seit jeher propagiert wird. Das weiß sogar ich, und ich war insgesamt vielleicht 5 Minuten auf der AROS-Webseite... Nachtrag - auf http://www.aros.org/introduction/ steht zu lesen: "Should be binary compatible on Amiga and source compatible on any other hardware." Sprich, die ABI ist die der Zielplattform. D'oh. Zitat:Zitat:woher hast du denn die Weisheit.du solltest dich mal wieder mit amigaos beschäftigen. Wofür, glaubst Du, steht das "k" in kprintf()? (Und bedenke, das AmigaOS 3.x nicht zwischen Kernel und Anwendung trennt...) [ Dieser Beitrag wurde von Solar am 12.10.2005 um 11:36 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
14.10.2005, 15:08 Uhr Kaesebroetchen Posts: 643 Nutzer |
Unter diesem Link: http://amidevcpp.kilu.de/Examples/Bitoperation.zip habe ich ein kleines Reaction Projekt abgelegt. Wäre super, wenn sich das mal jemand anschauen könnte. Aus irgendeinem Grund wird nämlich die WHMI_GADGETUP Message nicht verarbeitet. Ich komme da irgenwie nicht weiter... -- http://amidevcpp.kilu.de/ [ - Antworten - Zitieren - Direktlink - ] |
14.10.2005, 15:58 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich hab's mir noch nicht angesehen, will aber schonmal darauf hinweisen, daß GADGET_UP-Messages normalerweise nur gesendet werden, wenn RELVERIFY (oder so ähnlich) true ist. Sonst gibt's nur GADGET_DOWN. Vielleicht liegt's ja daran. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
15.10.2005, 09:48 Uhr Mazze Posts: 263 Nutzer |
Zitat: Email ist raus. -- Meine Homepage [ - Antworten - Zitieren - Direktlink - ] |
16.10.2005, 21:38 Uhr Kaesebroetchen Posts: 643 Nutzer |
@Mazze: Danke für die mail ! -- http://amidevcpp.kilu.de/ [ - Antworten - Zitieren - Direktlink - ] |
17.10.2005, 17:07 Uhr Kaesebroetchen Posts: 643 Nutzer |
@whose Wirf mal einen Blick auf deine emails (gmx Adresse) -- http://amidevcpp.kilu.de/ [ - Antworten - Zitieren - Direktlink - ] |
20.10.2005, 22:03 Uhr Kaesebroetchen Posts: 643 Nutzer |
Hab dir wegen der OS4 Version ne mail geschrieben. -- http://amidevcpp.kilu.de/ [ - Antworten - Zitieren - Direktlink - ] |
20.10.2005, 23:24 Uhr whose Posts: 2156 Nutzer |
@Kaesebroetchen: Ok, ich kümmer mich morgen nachmittag mal drum und teste ein wenig Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233 [ - Antworten - Zitieren - Direktlink - ] |
24.11.2005, 19:59 Uhr Kaesebroetchen Posts: 643 Nutzer |
Hat jemand hier im Forum schon mal AmiDevCpp unter Windows9x (95,98,me) installiert und falls ja, gibt es damit irgendwelche Probleme ? -- http://amidevcpp.kilu.de/ [ - Antworten - Zitieren - Direktlink - ] |
06.01.2006, 16:10 Uhr Clydos Posts: 68 Nutzer |
Hi! Ich habe AmiDevCpp 0.4 unter WinXP installiert - allerdings hatte ich vorher schon die aktuelle DevCpp darauf installiert! Selbstverständlich habe ich AmiDevCpp in ein anderes Verzeichnis installiert, aber trotzdem bekomme ich jetzt die Ami-Einstellungen, wenn ich den "normalen" DevCpp starte. :-((( Dies ist _sehr_ ungeünstig im Moment für mich. Woran liegt das und wie kann ich das beheben (am besten so, dass ich beide Installationen drauf habe)? Heißen Dank! Finde das Projekt und die Idee klasse! Werde mir aber vermutlich trotzdem Cubic holen. :-) MdG -- CD32 + SX-1 Heute schon geluxt? [ - Antworten - Zitieren - Direktlink - ] |
06.01.2006, 17:21 Uhr Kaesebroetchen Posts: 643 Nutzer |
@Clydos: Hallo Clydos, das Problem ist, das Dev-Cpp die Einstellungsdaten in der Datei Dev-Cpp.ini speichert welche sich im Ordner Dokumente und EinstellungenDev-Cpp befindet. AmiDevCpp überschreibt diese Einstellungen. Du musst also diese Ini Datei so anpassen, das Sie so aussieht: code:[CompilerSets_0] gcc.exe=gcc.exe g++.exe=g++.exe gdb.exe=gdb.exe make.exe=make.exe windres.exe=windres.exe dllwrap.exe=dllwrap.exe gprof.exe=gprof.exe Options= cmdline= LinkLine= CompAdd=0 LinkAdd=0 Bins=C:CrossCompilerAmiDevCppBin C=C:CrossCompilerAmiDevCppinclude Cpp=C:CrossCompilerAmiDevCpplibgccmingw323.4.2include;C:CrossCompilerAmiDevCppincludec++3.4.2backward;C:CrossCompilerAmiDevCppincludec++3.4.2mingw32;C:CrossCompilerAmiDevCppincludec++3.4.2;C:CrossCompilerAmiDevCppinclude Lib=C:CrossCompilerAmiDevCpplib [Options] Version="4.9.9.2" Language="English.lng" Theme="New Look" First=0 Splash="" MRUMax=10 DblFiles=0 NoSplashScreen=0 MinOnRun=0 OpenStyle=0 BackUps=0 AutoOpen=2 MsgTabs=1 ShowBars=0 ShowMenu=1 DefCpp=0 ShowOutput=0 OutputOnNeed=1 OutputHeight=120 ProjectView=1 ClassView=0 ProjectWidth=161 Statusbar=1 FullScreen=0 FindCols="75, 75, 120, 150" CompCols="75, 75, 120" ToolbarMain=1 ToolbarMainX=11 ToolbarMainY=2 ToolbarEdit=1 ToolbarEditX=201 ToolbarEditY=2 ToolbarCompile=1 ToolbarCompileX=11 ToolbarCompileY=30 ToolbarProject=1 ToolbarProjectX=375 ToolbarProjectY=2 ToolbarOptions=1 ToolbarOptionsX=143 ToolbarOptionsY=30 ToolbarSpecials=1 ToolbarSpecialsX=202 ToolbarSpecialsY=30 ToolbarSearch=1 ToolbarSearchX=261 ToolbarSearchY=2 ToolbarClasses=1 ToolbarClassesX=11 ToolbarClassesY=58 AssociateCpp=1 AssociateC=1 AssociateHpp=1 AssociateH=1 AssociateDev=1 AssociateRc=1 AssociateTemplate=1 ShowTipsOnStart=1 LastTip=17 XPTheme=1 FileDate=844534490 ShowProgress=1 AutoCloseProgress=0 PrintColors=1 PrintHighlight=1 PrintWordWrap=0 PrintLineNumbers=0 PrintLineNumbersMargins=0 WatchHint=1 WatchError=1 [Position] WinPlace=2, 3, -1, -1, -1, -1, 144, 131, 1008, 733 [Compiler] UseParams=1 InterDir= OutputDir= RunParams= Log=0 Delay=0 gcc.exe=i686-aros-gcc.exe g++.exe=i686-aros-g++.exe gdb.exe=gdb.exe make.exe=make.exe windres.exe=windres.exe dllwrap.exe=dllwrap.exe gprof.exe=gprof.exe CompilerSet=2 Options=0000000000000000000000 [Makefile] FastDep=1 [Editor.Font] Charset=1 Color=-2147483640 Name="Courier New" Pitch=0 Size=10 [Editor.Gutterfont] Charset=1 Color=-2147483640 Name="Terminal" Pitch=0 Size=9 [CompilerSets_1] gcc.exe=m68k-amigaos-gcc.exe g++.exe=m68k-amigaos-g++.exe gdb.exe=gdb.exe make.exe=make.exe windres.exe= dllwrap.exe=dllwrap.exe gprof.exe=gprof.exe Options=0000000000000000000000 cmdline=-noixemul LinkLine= CompAdd=1 LinkAdd=0 Bins=C:CrossCompilerAmiDevCppusrlocalamigabin;C:CrossCompilerAmiDevCppusrlocalamigam68k-amigaosbin;C:CrossCompilerAmiDevCpputilsbin;C:CrossCompilerAmiDevCppbin;C:CrossCompilerAmiDevCppusrlocalamigalibgcc-libm68k-amigaos2.95.3 C=C:CrossCompilerAmiDevCppusrlocalamigam68k-amigaossys-include;C:CrossCompilerAmiDevCppusrlocalamigam68k-amigaosinclude;C:CrossCompilerAmiDevCppusrlocalamigaincludeg++-3 Cpp=C:CrossCompilerAmiDevCppusrlocalamigam68k-amigaossys-include;C:CrossCompilerAmiDevCppusrlocalamigam68k-amigaosinclude;C:CrossCompilerAmiDevCppusrlocalamigaincludeg++-3 Lib=C:CrossCompilerAmiDevCppusrlocalamigam68k-amigaoslib;C:CrossCompilerAmiDevCppusrlocalamigam68k-amigaosliblibnix [CompilerSets_2] gcc.exe=i686-aros-gcc.exe g++.exe=i686-aros-g++.exe gdb.exe=gdb.exe make.exe=make.exe windres.exe=windres.exe dllwrap.exe=dllwrap.exe gprof.exe=gprof.exe Options=0000000000000000000000 cmdline= LinkLine= CompAdd=0 LinkAdd=0 Bins=C:CrossCompilerAmiDevCppusrlocalamigabin;C:CrossCompilerAmiDevCppusrlocalamigai686-arosbin;C:CrossCompilerAmiDevCpputilsbin;C:CrossCompilerAmiDevCppbin C=C:CrossCompilerAmiDevCppusrlocalamigai686-arossys-include Cpp=C:CrossCompilerAmiDevCppusrlocalamigai686-arossys-include;C:CrossCompilerAmiDevCppusrlocalamigaincludeg++-3 Lib=C:CrossCompilerAmiDevCppusrlocalamigai686-aroslib [CompilerSets] 0=Default compiler 1=m68k-AmigaOS 2=i686-aros [Directories] Exec="C:CrossCompilerAmiDevCpp" Config="C:Dokumente und EinstellungenAdministratorAnwendungsdatenDev-Cpp" Bins="C:CrossCompilerAmiDevCppusrlocalamigabin;C:CrossCompilerAmiDevCppusrlocalamigai686-arosbin;C:CrossCompilerAmiDevCpputilsbin;C:CrossCompilerAmiDevCppbin" Default="C:CrossCompilerAmiDevCpp" C="C:CrossCompilerAmiDevCppusrlocalamigai686-arossys-include" Cpp="C:CrossCompilerAmiDevCppusrlocalamigai686-arossys-include;C:CrossCompilerAmiDevCppusrlocalamigaincludeg++-3" Help="Help" Icons="Icons" Lang="Lang" Lib="C:CrossCompilerAmiDevCppusrlocalamigai686-aroslib" Templates="Templates" Themes="Themes" [Editor] AutoIndent=1 InsertMode=1 TabToSpaces=1 SmartTabs=1 SmartUnindent=1 TrailBlank=0 GroupUndo=1 EHomeKey=0 PastEOF=0 PastEOL=0 DblClkLine=0 FindText=1 Scrollbars=1 HalfPageScroll=0 ScrollHint=1 SpecialChars=0 AppendNewline=1 AutoCloseBrace=0 TabSize=4 MarginVis=1 MarginSize=80 MarginColor=-2147483626 InsertCaret=0 OverwriteCaret=0 InsDropFiles=0 GutterVis=1 GutterAuto=0 LineNumbers=0 LeadZero=0 FirstLineZero=0 Gutterfnt=1 GutterSize=32 UseSyntax=1 SyntaxExt="c;cpp;h;hpp;cc;cxx;cp;hp;rh;" DefaulttoPrj=0 ParserHints=1 Match=0 HighCurrLine=1 HighColor=16777164 [Editor.Syntax] Assembler=clBlue, clNone, 0, 0, 0 Character=clBlack, clNone, 0, 0, 0 Comment=clHighlight, clNone, 0, 1, 0 Float=clPurple, clNone, 0, 0, 0 Hexadecimal=clPurple, clNone, 0, 0, 0 Identifier=clBlack, clNone, 0, 0, 0 Illegal Char=clBlack, clNone, 0, 0, 0 Number=clPurple, clNone, 0, 0, 0 Octal=clPurple, clNone, 0, 0, 0 Preprocessor=clGreen, clNone, 0, 0, 0 Reserved Word=clBlack, clNone, 1, 0, 0 Space=clBlack, clWhite, 0, 0, 0 String=clRed, clNone, 0, 0, 0 Symbol=clBlack, clNone, 0, 0, 0 Break points=16777215, 255 Error Line=16777215, 128 Active Breakpoints=16777215, 16711680 Gutter=0, -2147483633 Selected text=16777215, 8388608 [CodeCompletion] Width=320 Height=240 Delay=500 BackColor=-2147483643 Enabled=1 UseCacheFiles=1 [ClassBrowsing] Enabled=1 ViewStyle=0 ParseLocalHeaders=1 ParseGlobalHeaders=0 ShowFilter=0 UseColors=1 ShowInheritedMembers=0 [CVSHandler] Executable="cvs.exe" Compression=4 UseSSH=1 [ExternalPrograms] Dummy=0 [History] 0=C:Amiga_PlattenAmigaDev2cppBitoperationBitoperation.dev 1=C:CrossCompilerAmiDevCppProjekt1.dev Das Compilerset_0 (das oberste) ist der MinGW32 für die Windows Programmierung. Du musst natürlich die Pfade anpassen. In meiner Installation habe ich alle Compiler im Pfad C:CrossCompilerAmiDevCpp. Bei dir dürfte der MinGW32 wohl in C:Dev-Cpp zu finden sein. Um Amigaprogramme zu kompilieren, musst du dann natürlich m68k_amigaOS als Compilerset auswählen. Wenn ich Zeit habe (und Hyperion mir endlich auf meine Mail antwortet) werde ich ein wunschlos glücklich Paket schnüren. Dann wird man mit einer AmiDevCpp Installation Programme für Windows, Classic Amiga, OS4, Morphos und AROS erzeugen können. -- http://amidevcpp.kilu.de/ [ - Antworten - Zitieren - Direktlink - ] |
06.01.2006, 17:31 Uhr Clydos Posts: 68 Nutzer |
@Kaesebroetchen: Wow, danke für diesen Hammer. :-) Hat hier ganz schön das Layout zerhauen. :-) Vielleicht kann man das noch anders gestalten? Aber zum Thema: Das hilft mir natürlich sehr, danke! Demzufolge erstelle ich mir einfach 2 ini-Dateien, eine für PC und eine für Ami. Klasse, danke, muss ich am WE mal ausprobieren. Wegen Mail an Hyperion: Das "Prob" kenne ich auch. :-/ Aber ich habe hier ja super Hilfe gefunden (@whose)! -- CD32 + SX-1 Heute schon geluxt? [ - Antworten - Zitieren - Direktlink - ] |
06.01.2006, 17:44 Uhr Kaesebroetchen Posts: 643 Nutzer |
@Clydos: Eine ini reicht völlig. Bisher ist sowohl das Default Compiler Set als auch Amiga m68k für Amigaprogramme. Wenn du es so änderst wie oben beschrieben, dann ist das Default Compiler Set für windows und das m68k_amigaos für Amigaprogramme. -- http://amidevcpp.kilu.de/ [ - Antworten - Zitieren - Direktlink - ] |
06.01.2006, 17:47 Uhr Clydos Posts: 68 Nutzer |
@Kaesebroetchen: Ah, I see! Danke! _So_ detailiert hatte ich mir die ini nicht angeschaut. :-) Super! Steht das in irgendeiner Dokumentation zum Paket/auf der Seite? Wäre sinnvoll und hilfreich! -- CD32 + SX-1 Heute schon geluxt? [ - Antworten - Zitieren - Direktlink - ] |
07.01.2006, 00:44 Uhr Clydos Posts: 68 Nutzer |
@Kaesebroetchen: Vergiß mein letztes Posting ... :-) Hab die ini gefunden, zumal der Pfad ja auch in Deiner ini da stand. Sorry für die Hektik ... :-( Du hast also DevCpp nur einmal installiert, aber eben die alle Crosscompiler und wechselst das Set nur über die ini - cool, ich hoffe, ich kann das so ohne weiteres auch anpassen/kopieren. Welche Dateien/Verzeichnisse müsste ich denn in meine Bestehende DevCpp-Installation kopieren? Oder geht das doch nicht so ohne weiteres? Gruß und gute Nacht -- CD32 + SX-1 Heute schon geluxt? [ - Antworten - Zitieren - Direktlink - ] |
07.01.2006, 01:58 Uhr Kaesebroetchen Posts: 643 Nutzer |
Zitat: Ich wechsle den Compiler über das Menü Projekt->Projekt Optionen Zitat: Im Prinzip kannst du den Inhalt des Dev-Cpp Verzeichnisses einfach in das AmiDevCpp Verzeichnis kopieren. Wenn du AmiDevCpp in C:CrossCompilerAmiDevCpp installiert hast, dann kannst du einfach meine Ini Datei übernehmen: http://amidev.kilu.net/AmiDevCpp_v05/devcpp.ini Die ist allerdings für Version 0.5 http://amidev.kilu.net/AmiDevCpp_v05/InetInstallerAmiDevCpp.exe müsste allerdings auch mit ein paar Fehlermeldungen mit Version 0.4 tun. -- http://amidev.kilu.net/ [ - Antworten - Zitieren - Direktlink - ] |
07.01.2006, 02:25 Uhr _PAB_ Posts: 3016 Nutzer |
@Clydos: Dein Beitrag wurde wegen eines Problems im Forum nicht eingefügt. Da Kaesebroetchen den aber sowieso wieder vergessen soll, habe ich ihn jetzt nicht wiederhergestellt... [ - Antworten - Zitieren - Direktlink - ] |
09.01.2006, 10:49 Uhr Clydos Posts: 68 Nutzer |
@Kaesebroetchen: Ich habe schon diesen Eintrag in den Kommantar vom MonsterPack geschrieben. Schreibe ihn aber sicherheitshalber auch nochmal hier rein. :-) -- Hey, klasse! Würde mir das gern ziehen, aber ich habe nur Highspeed-Netz in der Uni. Da nützt mir leider die Internet-Install-Datei nix. :-(( Und alle Pakete einzeln runterzuladen ist auch nicht gerade ideal. :-( Wäre es auch möglich, dass Du das Monsterpack direkt zum Download zur Verfügung stellst? Da könnte ich das hier runterladen und auf den Stick kopieren. Wäre klasse, wenn das ginge. Danke im Voraus! MdG -- CD32 + SX-1 Heute schon geluxt? [ - Antworten - Zitieren - Direktlink - ] |
09.01.2006, 11:05 Uhr Kaesebroetchen Posts: 643 Nutzer |
Dann antworte ich sicherheitshalber auch noch hier. Heinz-Raphael Reinke (09-Jan-2006, 11:02) @clydos Das geht nicht sorry. Ich benutze einen kostenlosen Webspace und der lässt nunmal keine Dateien > 1MB zu. Aber vielleicht stellt ja jemand etwas Webspace zur Verfügung,läd das Komplettpaket hoch und postet hier einen Link ? Notfalls kann ich dir das ganze auch auf CD brennen und gegen einen kleinen Unkostenbeitrag mit der Post schicken. -- http://amidev.kilu.net/ [ - Antworten - Zitieren - Direktlink - ] |
09.01.2006, 11:59 Uhr Holger Posts: 8116 Nutzer |
@Kaesebroetchen: Was genau muß man denn machen, um eine große Datei zu erhalten, die man wieder online stellen könnte? Ich mein insb. wegen Installation .exe oder so... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
09.01.2006, 12:22 Uhr Kaesebroetchen Posts: 643 Nutzer |
Zitat: Im Grunde einfach alles herunterladen und das selbstentpackende Archiv ausführen (AmiDevCpp.exe). Wenn du das Internet Setup ausführst, wird das automatisch gemacht. Das Installationspaket heisst dann AmiDevCpp_Setup_V09_Monster_Pack.exe und ist ca 90MB groß. P.S. Ich dachte immer du wärst Modem Nutzer ? -- http://amidev.kilu.net/ [ - Antworten - Zitieren - Direktlink - ] |
1 -2- 3 4 | [ - Beitrag schreiben - ] |
amiga-news.de Forum > Programmierung > AmiDevCpp | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |