InClean - Practical Difference When Used?

[Roger Garstang]

Yup, Paul is correct. I was going to make it work as an addon/Utility to FireFly too and had requested a couple variable types to be passed to it. Right now, FireFly does a pretty good job of parsing and if PB doesn't plan on doing it any time soon, it would almost be easier for an IDE like it to split the files like I mentioned above and only include the declares for the functions used in the code.

I believe I still have the source for incLean backed up somewhere. Borje seemed to not mind in giving it to me to try my hand at, but before passing around someone else's code I'd still want to get confirmation from him...is he still around? I haven't seen much of him. Seems like PB gets some good minds then they disappear. Hopefully Bob has them all locked in a basement somewhere working on PB Linux and PB WinMobile.

[Paul Squires]

I think that at one point Borje sent the source to Roger. I remember him talking about it during FireFly 2 beta testing a number of years ago.

[Patrice Terrier]

Roger,

You write: "i got the source code" do you speak of pbcodec or inclean?

As far as i know, inclean source code has never been posted here.

[Roger Garstang]

I used to use it a lot too, but for the reasons Paul mentioned it became to where it wasn't working. I got the source code and was going to fix it, but it was pretty complicated and I didn't have as much free time as expected. I also agree that the compiler shouldn't compile functions not used...but I appear to have been forgotten in this wave of Beta testing, so my opinion will matter just about as much as everyone else.

I have taken MM's approach in most of my tight apps that really need it and just do what incLean did on my own to create a file with just what I need. The best approach would be to create your own files with just all Equates, Types, and Macros which the compiler does handle for you and another with just the Functions you use, that way you get the same effect.

Another side effect of how the compiler works currently is if you have a tool that looks at dependencies of your exe it looks like it uses all/most of the Windows DLL files when it really may only use some. PB also calls API internally too, so you will see DLLs needed when you use things like TCP, etc that you may not specifically call yourself.

[Patrice Terrier]

URL to zXref

[Patrice Terrier]

Currently zXref is based on pbcodec, but my plan is to create both the Xref and the cleaned source code in one single pass.

So far, zXref is more than twice faster than the original pbcodec, using plain SDK and latest PB9 string manipulation goodies.

...

[Gary Beene]

So, while I find the output of incLean (the way it's spelled on the app window) useful, I get the impression that it's not used that much - the benefits are there, but are just not overwhelming enough to draw most programmers to use it regularly.

Patrice, a combo of pbcodec and incLean would be nice. Is your utility going to cover both, or just pbcodec.

[Jeff Blakeney]

First, I'm pretty sure the program in question is called INClean or INC lean as opposed to In Clean because it makes your INClude files LEAN.

Second, another benefit to using this type of program to create a single include file with only the equates and declares your program needs is that you can archive that include file with the source and you don't need to worry about changes to files like WIN32API.INC making your program either not compile or not work properly in the future.

[jcfuller]

I'm working on a Parser Class and used it to incorporate all of the Declares in José's Include files to just one file. I use a Buffer Class that returns a cleaned up (no remarks) complete line (removes line continuations) and extra spaces. Unfortunately I painted myself into a corner with this one as many of the declares exceed the 240 character line limit of the compiler. Back to the drawing board.

James

[Patrice Terrier]

James

I don't know yet, maybe hidden listbox to store data and pointers.

I am currently in the process to cleanup the pbcodec code from any API encapsulation, while adding the new PB9 string builder BUILD$ that is a nice addition.

I shall post zXref (the new name) to José Roca's as soon as i am done with it.

...

[jcfuller]

Inclean and its brother pbcodec are two nice utilities from the beloved Börje Hagsten.

It helps to produce smaller EXE by removing the unused code from a project (.bas + .inc).

I also think that PowerBASIC should have a preprocessor option to do what inclean does, that would be a great addition to the compiler itself.

I am currently translating pbcodec into full SDK, to see if i could start from it and write a new version of inclean (source code has never been published). This would be a good addition to my zTrace utility.

...

Patrice,
What will you use for your lookup?
I wrote a utility years ago that did a similar thing but did not parse the source. Instead I compiled with no INCLUDES, highlighted the offending code that would not compile and did a lookup -> add to new INCLUDE. I used the PowerBASIC Win32Api.Inc.(a real hack to be sure)
But now I use José's Includes and with over 900 include files it becomes a bit daunting on how to begin?

James

[Fred Buffington]

Besides the modest compiled size reduction, it makes a separate file that is easy to add equates, etc., if needed. I still use it because I have not compiled any applications other than samples from this forum and the PB9
subdirectories with version 9 so any differences in the API calls from version 8 to 9 that may come up have not affected me yet. With DDT I think this will be less of a concern anyway than with SDK.

[Patrice Terrier]

Inclean and its brother pbcodec are two nice utilities from the beloved Börje Hagsten.

It helps to produce smaller EXE by removing the unused code from a project (.bas + .inc).

I also think that PowerBASIC should have a preprocessor option to do what inclean does, that would be a great addition to the compiler itself.

I am currently translating pbcodec into full SDK, to see if i could start from it and write a new version of inclean (source code has never been published). This would be a good addition to my zTrace utility.

...

[Michael Mattias]

>Personally, it would be cool if all of the InClean type of functionality
> was built into the compiler.

As in "don't compile procedures unless called in this module or EXPORTed?"

(I'll bet someone forgot that "unused" procedures need to be compiled if exported!)

MCM

[Paul Squires]

It just makes compiling a little faster (less include file parsing) and it results in a few kilobytes less in the final compiled EXE. I don't think that InClean works well with the recent WinAPI includes due to the conditional equates found in the newer includes. I stopped using InClean a couple of years ago because of that. With faster processors these days the benefit of InClean is marginal. I have used it in some of my DLL projects because it shaves off a few K from the DLL.

Personally, it would be cool if all of the InClean type of functionality was built into the compiler.

[Gary Beene]

I was looking at InClean, which pulls out code from Include files as needed to support a program. The pulled code can be copied over into the app to remove the need for the Include files when compiling.

Other than perhaps compiling faster, are there other reasons to do this? The PowerBASIC compiler is already very fast so another 1/4 second of the compile time is not an issue for my 10K lines of program code.

Do really large apps take much longer to compile?
Is the final EXE smaller/faster?

Just wondering.

I used InClean on my apps and discovered that I had used some macros - which was fine, I just didn't realize that I had done so. It's always nice to analyze the content of an app and see what's there. Sometimes you can be surprised, especially if the work was spread out over time.