allegro mit Watcom Compiler

Tom555

ja, zuerst das fix.bat watcom und dann make.
Beim make ist er aber dann eben an dieser Stelle hängen geblieben.

elise

oki

schau dir mal den makefile an

http://cvs.sourceforge.net/viewcvs.py/alleg/allegro_new/makefile.wat?rev=1.2

er braucht ... wie du oben stehen siehst.. den djgpp für die assemblerübersetzung.
ich denke nicht, daß es ohne geht.

später unten ist auch die stelle, wo es hängt.

# This build uses djgpp for building the assembler sources and calculating
# source dependencies, so you'll need to have that installed as well.

keine ahnung, ob es irgendwie auch ohne geht, ich kenne es nur mit

Tom555

den djgpp hab ich ja drauf, das makefile läuft ja auch schon ein Stück. Brauch ich etwa noch einen 2. djgpp um den Assemblerteil da durchzubringen ?

elise

hmm hast du diesen zip picker zur installation benutzt?

http://www.delorie.com/djgpp/zip-picker.html

schau mal, ob du das bnu packet dabei hast.

apropo, wenn der watcom einfach streikt aus unerklärlichen gründen (was aber nicht sein sollte), versuche alles einfach im djgpp im grunde ist meines wissens allegro ursprünglich für den djgpp geschrieben worden.

wenn das durchläuft, würde ich mich später nochmal an den watcom wagen. ich habe verschiedene allegro versionen, eine für den djgpp, eine für das studio...

bei mir existiert eine asmdef.exe, wie dem makefile entnomment bildet sie sich aus asmdef.c. allein aus dem namen schließe ich, daß sie dazu die basic klassen in bnu braucht.

so long

Tom555

Den hab ich schon genommen den Zip Picker, das bnu Paket hab ich auch. Ich hab auch die asmdef.c aber wenn er die kompilieren will um die asmdef.exe zu erstellen schmiert er ab.

Könntest du mir die asmdef.exe mal schicken, wenn ich die reinkopiere dann geht er vielleicht drüber

elise

er würde nur drübergehen, wenn du es aus dem makefile rausholst..

mein eindruck ist übrigens, daß er unterschiedliche asmdef.exe herstellt. für das studio hat sie eine andere größe bei mir.

vielleicht schaut ja jemand rein, der schonmal mit watcom gearbeitet hat.

wie gesagt, für eine erste runde allegro testing eignet sich der djgpp auch sehr gut.

ps: schick mir deine email, sonst kann ich nix anhängen

Tom555

Wenn er immer andere compiliert bringts wohl nix. Dann werd ich wohl mit dem Dev-C weitermachen obwohl der ewig viele Macken hat.

Danke für deine Hilfe soweit.

Tom

elise

ich verstehe dein anliegen nicht.

wenn du allegro programmieren willst, dann mach es doch einfach mit dem djgpp, so du ihn sowieso schon drauf hast.
es ist ein ordentlicher compiler

bei mir existieren drei compiler friedvoll nebeneinander, und mit jedem mache ich andere sachen..

so long

Tom555

Mein Anliegen war dieses :

Ich programmiere zur Zeit Allegro mit dem Dev-Cpp von Bloodshed. Es funktioniert ja alles recht gut aber der hat halt einige Bugs. Ich habe aber noch eine Vollversion vom Watcom zuhause und dachte deshalb ok nimmst halt den mal wieder der hat wenigstens nicht so viele Bugs. Aber wens nicht geht was solls, dann nehm ich halt den her den ich eh schon am laufen hab. An die Bugs gewöhnt man sich mit der Zeit schon.

Tom

EDIT!:
Das könnten Path-Probleme sein, wobei ich nicht weiß, wie das nun in XP gehandhabt wird, aber Einträge für den Dev-C++ sollten unbedingt versteckt werden.
Und dann sollte es wohl einen Ersatz für alte autoexec-Einträge geben, sodass die beiden Anweisungen für den DJGPP (path und environment-variable - siehe ZIP-Picker) noch eingetragen werden müssen.
Kann Dir trotzdem nicht sagen, ob da ein spezifisches XP-Problem auftaucht - aber ich bin ziemlich sicher, dass es diese Environment-Dinge sind.

@elise:
Seitdem die RHIDE von diesem Nachfolge-Autor betreut wird, macht das mit dem DJGPP keinen Spass mehr. Die hat nun etliche neue (Memoryleak)Bugs, sodass die DJGPP-Gurus ganz schön sauer auf den Herrn sind. Dazu kommt, dass es nun sehr grosse Probleme beim Sourcecode-Debugging gibt, da offensichtlich die Einbindung der neuen Debugger-Versionen auch schlampig gemacht wurde.
Also - jener Herr hat sich da etwas übernommen! Auch irgendwie ein Zeichen der Zeit... Vielleicht sind aber auch mittlerweile alle Programme zu komplex geworden, um ordentlich gewartet zu werden. Da hilft auch OOP und UML nicht.
Jene, aus alten Zeiten weiterentwickelten, Dinge lassen sich wohl keine ordentlichen Schnittstellen mehr aufprägen - ohne komplett neu strukturiert zu werden. Und das, wo Linux immer mehr an Bedeutung gewinnt und ohne den gcc wohl undenkbar ist. Da prallen ein paar Welten aufeinander...