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

Hi Saskia.

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 Monique.

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 <paratiritis.the.forthnet...@popper.forthnet.gr> wrote in article
<32B063B0.5...@popper.forthnet.gr>...

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.

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,

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