TOPIC:

Hi,

I tried new CT 5.20 (previous versions worked fine), and it fails to build (either from install.bat, or from CTC) codetyphon. The reason reported is that System unit is missing, and truly so, when I checked unit paths in fpc.cfg, there is no directory c:\codetyphon/fpc/fpc32/units/.

OS Win 7 x64

Any attmpt to build Typhon (x86|x64 ; Small/Big IDE) will fail.

Is this "normal" for 5.20, or special to just my fu*ked-up instance of Windoze ?

Would you like any additional info ?

Thanks for any pointers,

carlok.

Can you publish more information? How you produce the installation? Do you read the installation instruction?
Is this fresh install or upgrade?

> How you produce the installation
As usual, unpack the codetyphonins dir to secondary drive (f:\codetyphonins; at least past versions worked fine from whatever drive), run install.bat, selected the obvious option (install), waited, then selected run CTC. tried several times to build big and then small ide (32bit).

afterwards, i first deleted c:\codetyphon, re-installed, and tried building typhon from the .bat wrapper instead of from CTC. this tried to build 64bit ide, i think.

same problem every time, no system unit.

>Do you read the installation instruction
First time (few versions back) i did, it just worked every time (on several computers, this one included).. since the install went fine without errors, i did not re-read them. re-checked now just to be sure, and there still isn't anything important, just the same old boring "unpack-run-expect it to work" stuff.

>Is this fresh install or upgrade?
I'd say fresh. it is not the first time that typhon was installed on this particular machine, but i fully deleted previous version (whole codetyphon dir), and after first failure i tried the "clean configuration" and "clean <appname>" cause they could hardly make things worse

Sir
please give us more info:
-Do you have lazarus installed ?
-Has the installation user administrator privileges ?
-Installation user name has only English letters and without spaces. ?
-Did you install System Libraries ?

-Do you have lazarus installed ?
no

-Has the installation user administrator privileges ?
of course, the install script checks this.

-Installation user name has only English letters and without spaces. ?
yup

-Did you install System Libraries ?
Only two missing are D3DXOF & D3D8.dll (both 64bit). It never mattered in the past. How do the base FPC units depend on D3D anyway ?

---

It occured to me you might want to check build logs from CTC. For simplicity, I tried building just 32bit FPC and even this fails. No directory C:\codetyphon\fpc\fpc32\units
Attaching log.

Thanks for your time,
Carlok.

Sir
At Line 19775:

C:/MinGW/bin/rm.exe -f ppc1.exe
C:/MinGW/bin/mv.exe -f ppc386.exe ppc1.exe

Build Procedure use rm.exe and mv.exe from C:/MinGW/bin/ directory
this is NOT normal.
CT build (Win32) procedure use rm.exe and mv.exe from C:\codetyphon\fpc\fpc32\bin\i386-win32 directory

My suggestion is to rename temporary MinGW folder before CT build procedure
or to remove from OS "path" the rm.exe and mv.exe executables
have fun..
..

Thank you very much. Although i've had mingw installed for a long time, just recently i merged msys into the mingw directories (some docs suggested it for fixing something), so those binaries appeared on path.

I'll make a launcher batch for CTC which will rectify this.

But if I might suggest, wouldn't it be better for typhon scripts and/or CTC to refer to bundled executables by full absolute/relative path ? This way, no existing binary could ever interfere ...

Thanks again, good luck with future development.

Oh
CT has mingw32, mingw64 (GCC 4.9.0), msys and binutils for CT Cross-Build-Engine
ready for use...

PS: Cyclone IDE is for next CodeTyphon Generation

> CT has mingw32, mingw64 (GCC 4.9.0), msys and binutils for CT Cross-Build-Engine ready for use...

Nice, but i'll keep the independent copy. Not every language^*1 comes bundled with gcc&co (not every need it; but of those that do, nearly every "serious" one does so). And sooner or later, c:\mingw gets messed up, no need to use typhon for this purpose .

But still, calling tools (which have known location) by their "full name" would foolproof typhon/cyclone against any and all random collisions (and since path would remain untouched, all other tools would still work all the time, regardless of "environment inheritance"). [just giving a rationale, not arguing it is necessary]

> Cyclone IDE is for next CodeTyphon Generation
will keep on lookout, lazarus still doesn't make FPC pleasant enough to use. If i were ever to consider object-pascal for serious work, I'd require something like "delphi without embarcadero".

Typhon is, IMO, already better editor, and has all the necessary features I like/require in IDE. Code navigation / formating etc is also lot better (and faster) than even XE7 with all those fancy plugins (GExperts, CnPack, Castalia, and delphi still sucks balls as a code editor ...). And i think i like Typhon Docking better.

The only more convenient thing in EX7 was that the textbox for searching components by name was just above the components sidebar, Typhon, i think, could only pop it up on demand (slight delay, but still better than scrolling throught 50 component groups ).

Hopefully Cyclone will be even more polished, FPC team will add runtime package loading & extended RTTI, and I (as well as Boian Mitov ) won't have further excuses not to use FPC.

Rock on

---

*1) I use a lot of prog. languages, some professionally (each sucks or lacks in a different way), and in my spare time i pretty much collect interesting languages i know/can use. Let's call it binary fetishism ))