How deep do you call IncludeFiles?

[PB]

THIS POLL IS NOW OBSOLETE.

But I guess it can stay up for curiosity's sake.
See my last post in this thread for the reason why:

viewtopic.php?p=68878

I don't want to re-invent the wheel, hehe.


--- Original message for this post ---
At viewtopic.php?t=12385 I'm having a small
problem of identifying recursive IncludeFiles in PureBasic sources. So before
I invest too much time working on a solution, I'd like to know if it's worth the
effort. Basically, I'd like to know if you use IncludeFiles in other IncludeFiles,
or whether you have one main source and only use IncludeFile in that. TIA.

[PolyVector]

Mine go so deep I get lost... I have a folder of modules I write... They have a folder of Includes... Some of my projects include other whole projects.... it gets rather insane...

[Dare2]

I tend not to use includes inside includes. I have a simplistic mind and I get confused/lost very quickly.

Here's something very rough and ready. (also from your thread)

http://www.tabturn.com/PureBasic/downlo ... cludes.zip

[PB]

> Here's something very rough and ready. (also from your thread)
> http://www.tabturn.com/PureBasic/downlo ... cludes.zip

Hi Dare2, I tried that file, but it failed to spot the IncludeFile in this line:

Code: Select all

pi=22/7 : IncludeFile "B.pb" : Debug pi

I need to be able to pick IncludeFile out of anywhere on a line. My parser
can do it, but I get lost when recursive IncludeFiles come into the picture.
I think I know a way to do it, but it'll take some coding and I'd rather avoid
if it possible; hence this poll to see if it's worth the effort.

[Dare2]

Klurgy fix to a klurgy prog, but this may do it. Just replace from stepper=0 to the wend with this:

Code: Select all

stepper=0
While stepper<fCtr
  srcfile=getFileName(stepper)
  createPathMap(srcfile)
  stepper+1
  fHnd=ReadFile(#PB_Any,srcfile)
  If fHnd=0
    Debug "ERROR: Not found "+srcfile
  Else
    UseFile(fHnd)
    While Eof(fHnd)=0
      w.s=Trim(ReadString())
      i=FindString(w,":",1)
      p=0
      While i
        p+1
        y.s=Trim(StringField(w,p,":"))
        x.s=UCase(y)+Space(12)
        If Left(x,12)="XINCLUDEFILE" Or Left(x,11)="INCLUDEFILE"
          processFileName(y)
        EndIf
        i=FindString(w,":",i+1)
      Wend
      p+1
      y.s=Trim(StringField(w,p,":"))
      x.s=UCase(y)+Space(12)
      If Left(x,12)="XINCLUDEFILE" Or Left(x,11)="INCLUDEFILE"
        processFileName(y)
      EndIf
    Wend
    CloseFile(fHnd)
  EndIf
Wend

Be interested to know if it does the job. If so, I'll tidy this up.

Edit: Small fix made.

[PB]

> Klurgy fix to a klurgy prog, but this may do it.
> Be interested to know if it does the job.

Yep, now it works -- and even recurses into a subfolder that I specified!

However, I am hesitant to use another person's code, especially yours which
seems to be quite a bit of work. I'm more inclined to stick with my code if the
poll shows that option #2 is the majority. I'll wait and see the results first.

[Dare2]

Good to know. What sort of info do you think is good/useful? Times referenced? Containing files? And what sort of output? To Text File? To Debug window?

[EDIT]
lol - theres a beaut of a bug in the above. Pure luck it worked.

[dmoc]

IMHO the reason you struggle with include(d) files is because of the way you have structured your code. Unless I am missing something, ie, a valid reason for inserting them in your code at the point required, a more manageable technique is to put all your include statements at the top of the file. The only exception I can think of is where you need to declare some vars/ structure before the include. This is the approach I am using on a large app split into more files than I can remember atm (I try to modularise as much as possible as I code).

Even then the limitations of PB for large apps is painfully clear: variable/function name clashes aka "namespaces". So I use three letter abbreviations prepended to all functions in a particular "module", eg, "afm...()" for "Advanced File Manager" functions and typically a single structure for each module to contain it's associated variables. This makes the whole codebase much more manageable but still not as much as I would like. So then I split each module into two, eg, "afm.pbi" and "afm-h.pbi", the latter being, surprise, the "header" file included in the former (there's a reason why C is so popular). Now I am thinking of yet another type of file, eg, "afm-i.pb" specifically for the includes but I don't think it's possible/practical considering the exception mentioned above. I recently made the mistake of combining several files into one "general utilities" file, without changing any actual code except to replace several includes (in several files) with the one include file. My compiled app jumped in size from ~300k to ~500k They say size doesn't matter anymore but tell that to the person receiving it via email.

Now the thought of going back through splitting includes into logical groups that the PB compiler uses more efficiently has put me off coding at all for the last few weeks. So yes I'd like a much better method for managing them. In fact I would like a repository integrated into PB in which I could store my documented and version controlled structures, interfaces and any/all other includes.

[PB]

> IMHO the reason you struggle with include(d) files is because of the way
> you have structured your code.

Wrong. It's because I was writing an app to parse ANYONE'S code, and
I have no way of knowing how structured THEIR code is. That's why it
becomes a struggle: because you can't envisage how they code. Further,
as this poll has shown, some people have nested (recursive) IncludeFiles,
which makes collating them all a difficult task. You parse the main source,
and get a list of included source files. Then you must parse those, which in
turn run the risk of including more. It becomes messy and difficult to get a
list like that, especially when you consider XIncludeFile and the fact that
IncludeFiles can be named from constants and so on. It's really a tough
thing to code: give it a try and you'll see.

> a more manageable technique is to put all your include statements at
> the top of the file

Depends on how you're using them. IncludeFiles are not just for definitions.
They can be anything -- even a single block of frequently-used code that
you wish to insert at any point, to save typing or pasting it in. Doing this
can keep your main source code small, and easier to navigate (a bit like
folding a procedure to keep it out of the way).