Board index » delphi » Huge list of unit directories to include

Huge list of unit directories to include

In our development environment we have about 60 different directories
(one for each SW area) were units can reside.  As the areas use units
from all kinds of different areas, we want to find a way to have the full
list of units in the BPC.CFG.
Currently we have separate make-rules for each possible combination, but
we want to get rid of that because it takes too much maintenance.
We tried already two possibilities:
Several lines with /U in BPC.CFG: results in compilation error.
A line with /U longer than 255 in BPC.CFG: characters after 255 are
ignored.
What is the solution?

 

Re:Huge list of unit directories to include


Saskia Vermylen <MYL...@btmaa.bel.alcatel.be> wrote in article
<32A8653F.3...@btmaa.bel.alcatel.be>...

Quote
> In our development environment we have about 60 different directories
> (one for each SW area) were units can reside.

[snip]

Quote
> Several lines with /U in BPC.CFG: results in compilation error.
> A line with /U longer than 255 in BPC.CFG: characters after 255 are
> ignored.

You could try using DOS's SUBST command to map new drive letters to
various key points in your list of directories. This way, you could reduce
the number of characters needed to describe the list.

Chris.

Re:Huge list of unit directories to include


Hi Saskia.

Quote
> In our development environment we have about 60 different directories
> (one for each SW area) were units can reside.  As the areas use units
> from all kinds of different areas, we want to find a way to have the full
> list of units in the BPC.CFG.

        If the used units reside in too many different directories the only
quick solution is to make a RAM-drive and copy unit's to that drive. Because
the drive is in memory the compilation will be quicker and the compiler doesn't
have to search through directories. For example You can make a batch file which
creates RAM drive, copies all unit sources to that drive and then runs make,
after that it would delete the RAM drive again. For creating dynamically RAM
drives You need some kind of utility programs but the RAM drive can also be
preallocated during system startup.

        Raul Rebane.

Re:Huge list of unit directories to include


Hi Raul,

This is Monique, I am one of the people in Saskia's group.  In your answer to Saskia you
talk about <the only quick solution>.
If I am a good reader, you know alsoo about another, not so fast solution ?????
I mean, in our test-environnement we get some new units about 20 peaces a day.  Working
with a RAM drive would mean we have to copie several times a day, all our sources (we talk
about 2500 source-files.
So we are still trying to find another solution.
We would be very glad if you could help us out.

Monique

Quote
>         If the used units reside in too many different directories the only
> quick solution is to make a RAM-drive and copy unit's to that drive. Because
> the drive is in memory the compilation will be quicker and the compiler doesn't
> have to search through directories. For example You can make a batch file which
> creates RAM drive, copies all unit sources to that drive and then runs make,
> after that it would delete the RAM drive again. For creating dynamically RAM
> drives You need some kind of utility programs but the RAM drive can also be
> preallocated during system startup.

>         Raul Rebane.

Re:Huge list of unit directories to include


Hi Monique.

Quote
> This is Monique, I am one of the people in Saskia's group.  In your answer to Saskia you
> talk about <the only quick solution>.

        Sorry about citing the solution that way. Ofcourse this isn't <the only>
solution. As I've also read the other postings You have got so far, they seem to be
a more resource hungry than the one I suggested (for example subst command). Now for the
problem of Yours again.

Quote
> If I am a good reader, you know alsoo about another, not so fast solution ?????
> I mean, in our test-environnement we get some new units about 20 peaces a day.  Working
> with a RAM drive would mean we have to copie several times a day, all our sources (we talk
> about 2500 source-files.

        If You take in account today's HDD's they are considerably faster then the older ones
giving You effective transfer rate about some MB's per second. Taking into account the disk
caching software will increase the number further. So taking this into account my solution
doesn't seem so bad. You can make a batch file that will copy the sources for You so You
don't have to type in lot of commands to execute. I can't see any other way to reduce the list
of directories other than that. Maybe just have to think it over but I'm currently having
near to deadline finishing my large project and I haven't really profiled my new units yet.

Quote
> So we are still trying to find another solution.
> We would be very glad if you could help us out.

> Monique

        I still offer my previous solution to You dear Monique. Hope You can find
better solution though.

        Raul Rebane

Re:Huge list of unit directories to include


Quote
vanwalleghem monique wrote:

> Hi Raul,

> This is Monique, I am one of the people in Saskia's group.  In your answer to Saskia you
> talk about <the only quick solution>.
> If I am a good reader, you know alsoo about another, not so fast solution ?????
> I mean, in our test-environnement we get some new units about 20 peaces a day.  Working
> with a RAM drive would mean we have to copie several times a day, all our sources (we talk
> about 2500 source-files.
> So we are still trying to find another solution.
> We would be very glad if you could help us out.

> Monique

Hi,

Before I can suggest a solution, there are a couple of questions I have
to ask.

1. Are all of your 60 or so unit directories likely to be used by every
program?

2. Are these just different directories or are they organized in some
form of directory tree?

Depending on your answers, I will try to provide some hints.

(1) If not all directories are used at the same time.

I have a similar situation on my machine. Some 4-5 directories are used
for general purpose units, which are needed by virtually any program,
while the rest 20-25 directories are project directories. All units (and
the main program) of each different project are located in that project's
directory.

So, for any specific project I only need the (not so many) general
purpose unit directories plus one (this project's directory). In the IDE
I create a .TP file for each project, and I just switch between projects
through the menu selection "Options/Load Options".

If you are using the command line compiler, you could create a different
.CFG file for each project and copy it over BPC.CFG before compiling.

(2) If the directories are peer directories and not forming any tree
structure.

In this case you could just name them as e.g. C:\BP\01, C:\BP\02, ...,
C:\BP\60, run the compiler from the common parent directory (C:\BP) and
use a /U command line option where the directories are named relative to
their common parent directory, such as:

        /U01;02;03;04;05;06;..;59;60

This way you can fit about 80 directory names in a 255-char command line.
Of course, this approach will not work from any directory other than,
say, C:\BP. To make your life easier, you could also maintain a text file
associating the numbered directories with a human readable description
(or their previous name).

Now regarding the other answers you have received:

I think the SUBST solution is very nice, but unfortunately there are not
60 different drive letters available.

The RAM-drive solution is also something that will work. Consider making
a utility program that scans your directories and copies to the RAM-drive
only the new or modified source files. The program can check if two
versions of a file are identical by comparing their date/time stamps
(findfirst/findnext will do), and it will not be difficult for it to
recursively scan nested directories as well. Doing this, the repeated
copy process before compilation will not require so much time.

I hope I have helped.

Greetings,

Votis

Re:Huge list of unit directories to include


Votis <paratiritis.the.forthnet...@popper.forthnet.gr> wrote in article
<32B063B0.5...@popper.forthnet.gr>...

Quote
> I think the SUBST solution is very nice, but unfortunately there are not
> 60 different drive letters available.

I wasn't suggesting that EVERY directory be assigned its own drive letter.
The
point was that if several directories were offshoots from a common
directory
then this common directory could be SUBST'd, reducing the number of
characters needed to spell out the other directories paths (using a false
root drive...).

Of course, the feasibility of this strategy depends on the exact
relationship
between the 60 directories in question, but I believe that it at least
presents
possibilities.

Chris.

Re:Huge list of unit directories to include


Quote
Votis wrote:

> vanwalleghem monique wrote:

> > Hi Raul,

Thanks for your suggestions.

I also made the remark for myselve that the SUBST (wich we infact already
use to reduce the number of characters in the directory names) can not be
used for all directories.  Or we should have a 60-character alphabet.

One of the problems is that our programmers are making links to other
directories, where we (the compilation and officialisation group) do not
have a view on to wich directories they all link.  
Currently we have a number (about 20) of make-files where we give
different directories in the units-search path.  But when people are
developing, they just add the new-used directory in their IDE, and don't
think that we have problems with compilation afterwards, if this
directory is not in the used make-rule.

Therefor we try to find a solution where we can include all directories
and avoid in this way problems at the official compilation environnement.

Anyway thanks for your hints,
we think we will be going for the RAM-drive solution, or for a fast-SCDI
drive.  I did not think about the update of only the changed sources,
your suggestion for findfirst-findnext is very welcome.

Kind regards,

Moniek

Re:Huge list of unit directories to include


Quote
Chris Rankin wrote:

You are wright Chris substitution of the main directories is partly a
solution  and that us what we did already long time ago.

We have a directory Q:\testsrce\source\ where all unit directories reside
unther. On this directory we substituted drive K: so we only have to
mention K:\units;k:\area1;.....

But still we have problems for compiling some area's where many
crosslinks to other areas are built in.

Anyway thanks for your suggestion.

Kind regards,

Moniek

Quote

> Votis <paratiritis.the.forthnet...@popper.forthnet.gr> wrote in article
> <32B063B0.5...@popper.forthnet.gr>...
> > I think the SUBST solution is very nice, but unfortunately there are not
> > 60 different drive letters available.

> I wasn't suggesting that EVERY directory be assigned its own drive letter.
> The
> point was that if several directories were offshoots from a common
> directory
> then this common directory could be SUBST'd, reducing the number of
> characters needed to spell out the other directories paths (using a false
> root drive...).

> Of course, the feasibility of this strategy depends on the exact
> relationship
> between the 60 directories in question, but I believe that it at least
> presents
> possibilities.

> Chris.

Re:Huge list of unit directories to include


Quote
vanwalleghem monique <walle...@btmaa.bel.alcatel.be> writes:
>Anyway thanks for your hints,
>we think we will be going for the RAM-drive solution, or for a fast-SCDI
>drive.  I did not think about the update of only the changed sources,
>your suggestion for findfirst-findnext is very welcome.

You don't have to write such a program. XCOPY /M will do.

Frank

Other Threads