IDE or compiler flaw - log file

[Ketil Krumm]

Whether this is technically a bug is open for discussion, but it must at least be a flaw:

Almost all the apps I write use a log file for logging errors and other "notable" events. The file is always located in the same directory as the app itself, and bears the same name except with a .LOG extension. Sounds familiar? It is - that's what the compiler log file is named, too, so my log files kpet getting overwritten.

Fine - so I turn off the compiler log file in the IDE. Now my files kept disappearing... I finally tracked it down to this: If you turn off log file generation, the IDE (or compiler, I don't know) will delete APPNAME.LOG if it exists, but not write a new one... This may be by design to make sure you don't confuse old log files with new compiler results, but if I say no log file I mean no log file. If i have an old file laying around that's my problem...

Ketil

[Dave Navarro]

The compiler itself is a 16-bit Windows application. Which means that it can not write to the console. So the only way for the compiler to communicate with the IDE is through the .LOG file.

Turning "on/off" .LOG file generation simply tells the IDE whether or not to delete the .LOG file when it's done compiling. The compiler still generates a .LOG file regardless.

It's a necessity since the compiler is 16-bit.

--Dave


------------------
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Fred Oxenby]

An easy way around this problem is to use the compiler-
directives correctly.

You DO NOT name your BAS-module the same as the application.
If I have an application named "SPIDER.EXE" my main
BAS-Module is named SPID_102.BAS (Versioning)
#Compile exe "SPIDER.EXE"
produces a logfile SPID_102.LOG




------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Ketil Krumm]

Fred,

I guess that's one way of doing it - I employ another. My modules and exe files are always named the same, regardless of version. When I finalize a version, build or whatever you want to call it The last two things I do is create the installer (if applicable) and copy all files onto a CD or similar. The directory on the CD is then called SPIDER102 (per your example).

The log files for some of my apps are sent via email from unattended systems, can be imported into databases automatically etc - giving them different names just adds unneeded complexity to the process.

Thanks for your thoughts, though - the idea is fine, but it wouldn't work well for me. I'd much rather live with the annoyance while developing and keep the log file names as is.

Regards,
Ketil


------------------

[Fred Oxenby]

Sorry I missunderstood.
So my reply is removed..
You are backing up your source not only creating an
installation-cd.....
Good thinking, you get the source readonly and cannot
misstakenly owerwrite them.
I have to implement that myself...
And hallo HUTCH! Good advice BEFORE your next Disk-crash


[This message has been edited by Fred Oxenby (edited March 03, 2000).]

[Eric Pearson]

Ketil --

It looks to me like the compiler's .LOG files are created in the same directory as the main source code file that is being compiled (or maybe it's the default directory at the moment that the compile is started) not (necessarily) the target directory. I never see .LOG files in the same directory as my final executables. If my program's main directory is \MYDIR I always store my source code in \MYDIR\SOURCE and use the #COMPILE metastatement to tell the compiler where to put the EXE or DLL. Wouldn't doing that solve your problem?

Actually the system I use is \projectname\SOURCE\modulename1\*.bas, and \modulename2\*.bas, etc. I also have \projectname\RESOURCE\etc. It makes things easy to find, and keeps the executable's runtime directory nice and clean.

Anyway, since you can basically tell the compiler where to put the .LOG files, I wouldn't call this a bug or a flaw in the compiler or IDE.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited March 03, 2000).]

[Ketil Krumm]

Fred,

Yes, the system I use for backing up source code works very well. I didn't use to do it that way - I just had the usual "point in time" backups, meaning that my source code was put on tape along with everything else every night when the server backups were run. It wasn't related to versions of the software. The current schema came about when a client required the ability to change and recompile any prior version of the software at any time. It works so well that I'm using it for almost all my projects now.

Eric,

I like the thought behind your subdirs - I'll have a look at implementing that for my projects. Most of my projects consist of relatively few files, but I do admit the project directory sometimes gets a bit crowded. Thanks!

And Dave, thanks for clarifying the reason behind this. I did know that the compiler is 16 bit, which is the reason for "no long file names" in includes etc, but I never thought of this aspect of that fact.



[This message has been edited by Ketil Krumm (edited March 04, 2000).]

[Scott Turchin]

I too found this issue a while back, and for *ME* the best way to handle it was simply like this:

Viper.inc
Viper.exe
Viper.bas
Viper.h
viper.log <- PowerBasic
Viper!.log <- My app


That was my workaround, which has led me to put ! on a lot of things *Grin*, I know another company that does that too, funny how that works....(Where I work)..


Scott

------------------
Scott
mailto:[email protected][email protected]</A>