Hello,

at the moment I organize my projects this way:

/proja           ---> includes dll, exe and dbf
/proja/source    ---> include all source, obj etc.

In the project.xpj I normally refer to

[projext.xpj]
.\pgm.exe
[..\pgm.exe]
sourcea.prg
sourceb.prg

This worked fine with Xbase++ since ever (as far is I remember).

VXbase doesn't get the idea.

I set up a new project in /proja/source (using /proja/source/pgm.exe). 
I remove the default main.prg and "add existing files". Everything is 
fine. If I change the properties of pgm.exe to "..\pgm.exe", all source 
code files are dropped, and there's no way to turn it back.

I think this behaviour is worth a PDR ...

This leads me to the question: how do you handle the separation of 
source and executable?


Kind regards,

Georg S. Lorrig

Georg Lorrig wrote:

> Hello,
> 
> at the moment I organize my projects this way:
> 
> /proja           ---> includes dll, exe and dbf
> /proja/source    ---> include all source, obj etc.
> 
> In the project.xpj I normally refer to
> 
> [projext.xpj]
> .\pgm.exe                      <- Attention!!!
> [..\pgm.exe]
> sourcea.prg
> sourceb.prg

Must be:

[projext.xpj]
   ..\pgm.exe

[..\pgm.exe]
   sourcea.prg
   sourceb.prg


> This worked fine with Xbase++ since ever (as far is I remember).
> 
> VXbase doesn't get the idea.
> 
> I set up a new project in /proja/source (using /proja/source/pgm.exe). 
> I remove the default main.prg and "add existing files". Everything is 
> fine. If I change the properties of pgm.exe to "..\pgm.exe", all source 
> code files are dropped, and there's no way to turn it back.

This one is currently broken and will be fixed for next release of
PreRelease that will be available soon.

Regards
   Andreas Herdt
   [Alaska Research & Development]

> I think this behaviour is worth a PDR ...
> 
> This leads me to the question: how do you handle the separation of 
> source and executable?
> 
> 
> Kind regards,
> 
> Georg S. Lorrig
>

Hello Andreas,

we use a little more complex directory structure:

a) generated parts from compiler and linker
/proja/bin --> dll and exe
/proja/obj --> obj, def, exp, lib

b) developed parts (source code .prg and .ch used with the editor)
/source/prg/part1 -->first part of prg files (according to the module 1)
.....
/source/prg/partn -->n part of prg files (according to the module n)
/source/prg/include --> .ch files

For each developed part we have separated .xpj files that produce .dll files
(only one of them
produce the main.exe file).
For example:
part1.xpj produces part1.dll
part2.xpj produces part2.dll (that makes a reference to the produced
part1.lib and part1.dll)
part3.xpj produces part3.dll (that makes a reference to the produced part1
and part2 .lib and .dll)
...
partn.xpj produces main.exe that makes reference to all previous generated
.dll and .lib files.

Will be possible to reprodue this enviroment in the next release of the
prerelease ?
I have already tried but in the current version that i downloaded today is
not possible.

This separation of around 12 dll and 1 exe files is necesary because the
size of the application
is too big, around 13 MB (so we have aprox. dlls from 300 KB to 15 MB and
the exe is 80 KB)

What is your opinion ?

Regards
Luciano




"Andreas Herdt" <andreas.herdt@alaska-research.com> wrote in message
news:hAd81130DHA.1640@S15147418...
> Georg Lorrig wrote:
>
> > Hello,
> >
> > at the moment I organize my projects this way:
> >
> > /proja           ---> includes dll, exe and dbf
> > /proja/source    ---> include all source, obj etc.
> >
> > In the project.xpj I normally refer to
> >
> > [projext.xpj]
> > .\pgm.exe                      <- Attention!!!
> > [..\pgm.exe]
> > sourcea.prg
> > sourceb.prg
>
> Must be:
>
> [projext.xpj]
>    ..\pgm.exe
>
> [..\pgm.exe]
>    sourcea.prg
>    sourceb.prg
>
>
> > This worked fine with Xbase++ since ever (as far is I remember).
> >
> > VXbase doesn't get the idea.
> >
> > I set up a new project in /proja/source (using /proja/source/pgm.exe).
> > I remove the default main.prg and "add existing files". Everything is
> > fine. If I change the properties of pgm.exe to "..\pgm.exe", all source
> > code files are dropped, and there's no way to turn it back.
>
> This one is currently broken and will be fixed for next release of
> PreRelease that will be available soon.
>
> Regards
>    Andreas Herdt
>    [Alaska Research & Development]
>
> > I think this behaviour is worth a PDR ...
> >
> > This leads me to the question: how do you handle the separation of
> > source and executable?
> >
> >
> > Kind regards,
> >
> > Georg S. Lorrig
> >
>

Luciano wrote:

Well, what you have is a quiet complex scenario.
unfortunatly we can not support such a complex
scenario with next release. But I think I can give a solution
for your problem.

First of all, what you describe was not possible with
pbuild up to now. It does not provide the seperation
of DLL, EXE and OBJ, DEF, EXP, LIB.
Nevertheless we allready have on our todo to give the
developers a way to distinguish between source files
and target files. You can get an idea with OBJ_DIR.
Here you can tell pbuild where to build the objects,
and from where to take them for linkage.
Our plan is to provide a TARGET_DIR to tell pbuild
where to build the output files to (exp, libs, dll, exe...)
This does currently work with EXE and DLL files, means
that the linker places them to TARGET_DIR.
(This is currently broken since VX does not know anything
about TARGET_DIR)

To your problem. As far as I can see you are doing the following:
Each developmer works on a module that relies on modules from
other developers. The dlls on which the developer depends is
taken from the directory where it is built to.

I would suggest:
Seperate build and deployment. This means that each developer
builds its modules. After this is done, the modules are copied
to a directory from which other developers take them for their own
work:

/source/dev1/               <- prg, xpj (first developer)
/source/dev2/               <- prg, xpj (second developer)

/bin                        <- dll, exe

The idea is that in dev1 and dev2 the devs can work independant.
After they have built the dlls, they are copied to /bin.
/bin is part of the environment variable PATH. In case
a DLL is needed, just request it and it will be automatically
taken from /bin.

We allready have added the POST_ACTION to pbuild.
   POST_ACTION = Copy my.dll my.lib my.obj \bin
will deploy the files as required.

Hope this helps and gives an overview into which direction
we are going to go.


Regards

   Andreas Herdt
   [Alaska Research & Development]

> Hello Andreas,
> 
> we use a little more complex directory structure:
> 
> a) generated parts from compiler and linker
> /proja/bin --> dll and exe
> /proja/obj --> obj, def, exp, lib
> 
> b) developed parts (source code .prg and .ch used with the editor)
> /source/prg/part1 -->first part of prg files (according to the module 1)
> .....
> /source/prg/partn -->n part of prg files (according to the module n)
> /source/prg/include --> .ch files
> 
> For each developed part we have separated .xpj files that produce .dll files
> (only one of them
> produce the main.exe file).
> For example:
> part1.xpj produces part1.dll
> part2.xpj produces part2.dll (that makes a reference to the produced
> part1.lib and part1.dll)
> part3.xpj produces part3.dll (that makes a reference to the produced part1
> and part2 .lib and .dll)
> ...
> partn.xpj produces main.exe that makes reference to all previous generated
> .dll and .lib files.
> 
> Will be possible to reprodue this enviroment in the next release of the
> prerelease ?
> I have already tried but in the current version that i downloaded today is
> not possible.
> 
> This separation of around 12 dll and 1 exe files is necesary because the
> size of the application
> is too big, around 13 MB (so we have aprox. dlls from 300 KB to 15 MB and
> the exe is 80 KB)
> 
> What is your opinion ?
> 
> Regards
> Luciano
> 
> 
> 
> 
> "Andreas Herdt" <andreas.herdt@alaska-research.com> wrote in message
> news:hAd81130DHA.1640@S15147418...
> 
>>Georg Lorrig wrote:
>>
>>
>>>Hello,
>>>
>>>at the moment I organize my projects this way:
>>>
>>>/proja           ---> includes dll, exe and dbf
>>>/proja/source    ---> include all source, obj etc.
>>>
>>>In the project.xpj I normally refer to
>>>
>>>[projext.xpj]
>>>.\pgm.exe                      <- Attention!!!
>>>[..\pgm.exe]
>>>sourcea.prg
>>>sourceb.prg
>>
>>Must be:
>>
>>[projext.xpj]
>>   ..\pgm.exe
>>
>>[..\pgm.exe]
>>   sourcea.prg
>>   sourceb.prg
>>
>>
>>
>>>This worked fine with Xbase++ since ever (as far is I remember).
>>>
>>>VXbase doesn't get the idea.
>>>
>>>I set up a new project in /proja/source (using /proja/source/pgm.exe).
>>>I remove the default main.prg and "add existing files". Everything is
>>>fine. If I change the properties of pgm.exe to "..\pgm.exe", all source
>>>code files are dropped, and there's no way to turn it back.
>>
>>This one is currently broken and will be fixed for next release of
>>PreRelease that will be available soon.
>>
>>Regards
>>   Andreas Herdt
>>   [Alaska Research & Development]
>>
>>
>>>I think this behaviour is worth a PDR ...
>>>
>>>This leads me to the question: how do you handle the separation of
>>>source and executable?
>>>
>>>
>>>Kind regards,
>>>
>>>Georg S. Lorrig
>>>
>>
> 
>

Hello Andreas,

Thanks for your comments, they are very good.

The complex scenario that we have is using the pbuild with the alaska
version 1.82
already. Since the initial xbase++ version we are using the pbuild PLUS OUR
OWN TOOL
like a rmake to create a .bat and to update the .xpj as necessary. If you
want, i can send you
an example of our .bat and .xpj in order that you can see how much we have
reached
using the curren pbuild options and probably you can give us tips to do it
better or
you can consider this complex environment for a future release of VX.

We do not separate modules by developers, we separate modules according to
the functionality that implements, for example: basic functions, general
functions,
sql database access, functions to print documents, maintenance, clients,
accounts,
etc... More than one developer can work on the same module at the same time
(by the way, we are using Microsoft Visual SourceSafe to control the source
code).
But all developers create all modules during the compile and link process in
their
own local developing environment.

We are trying to use the Xbase++ as much as posible and it could be great
if the VX give as the possibility to delete our own tools if the VX can
support the same and better.

What do think ? Thanks in advance.

Regards
Luciano


"Andreas Herdt" <andreas.herdt@alaska-research.com> wrote in message
news:0ymDNqD1DHA.3616@S15147418...
> Luciano wrote:
>
> Well, what you have is a quiet complex scenario.
> unfortunatly we can not support such a complex
> scenario with next release. But I think I can give a solution
> for your problem.
>
> First of all, what you describe was not possible with
> pbuild up to now. It does not provide the seperation
> of DLL, EXE and OBJ, DEF, EXP, LIB.
> Nevertheless we allready have on our todo to give the
> developers a way to distinguish between source files
> and target files. You can get an idea with OBJ_DIR.
> Here you can tell pbuild where to build the objects,
> and from where to take them for linkage.
> Our plan is to provide a TARGET_DIR to tell pbuild
> where to build the output files to (exp, libs, dll, exe...)
> This does currently work with EXE and DLL files, means
> that the linker places them to TARGET_DIR.
> (This is currently broken since VX does not know anything
> about TARGET_DIR)
>
> To your problem. As far as I can see you are doing the following:
> Each developmer works on a module that relies on modules from
> other developers. The dlls on which the developer depends is
> taken from the directory where it is built to.
>
> I would suggest:
> Seperate build and deployment. This means that each developer
> builds its modules. After this is done, the modules are copied
> to a directory from which other developers take them for their own
> work:
>
> /source/dev1/               <- prg, xpj (first developer)
> /source/dev2/               <- prg, xpj (second developer)
>
> /bin                        <- dll, exe
>
> The idea is that in dev1 and dev2 the devs can work independant.
> After they have built the dlls, they are copied to /bin.
> /bin is part of the environment variable PATH. In case
> a DLL is needed, just request it and it will be automatically
> taken from /bin.
>
> We allready have added the POST_ACTION to pbuild.
>    POST_ACTION = Copy my.dll my.lib my.obj \bin
> will deploy the files as required.
>
> Hope this helps and gives an overview into which direction
> we are going to go.
>
>
> Regards
>
>    Andreas Herdt
>    [Alaska Research & Development]
>
> > Hello Andreas,
> >
> > we use a little more complex directory structure:
> >
> > a) generated parts from compiler and linker
> > /proja/bin --> dll and exe
> > /proja/obj --> obj, def, exp, lib
> >
> > b) developed parts (source code .prg and .ch used with the editor)
> > /source/prg/part1 -->first part of prg files (according to the module 1)
> > .....
> > /source/prg/partn -->n part of prg files (according to the module n)
> > /source/prg/include --> .ch files
> >
> > For each developed part we have separated .xpj files that produce .dll
files
> > (only one of them
> > produce the main.exe file).
> > For example:
> > part1.xpj produces part1.dll
> > part2.xpj produces part2.dll (that makes a reference to the produced
> > part1.lib and part1.dll)
> > part3.xpj produces part3.dll (that makes a reference to the produced
part1
> > and part2 .lib and .dll)
> > ...
> > partn.xpj produces main.exe that makes reference to all previous
generated
> > .dll and .lib files.
> >
> > Will be possible to reprodue this enviroment in the next release of the
> > prerelease ?
> > I have already tried but in the current version that i downloaded today
is
> > not possible.
> >
> > This separation of around 12 dll and 1 exe files is necesary because the
> > size of the application
> > is too big, around 13 MB (so we have aprox. dlls from 300 KB to 15 MB
and
> > the exe is 80 KB)
> >
> > What is your opinion ?
> >
> > Regards
> > Luciano
> >
> >
> >
> >
> > "Andreas Herdt" <andreas.herdt@alaska-research.com> wrote in message
> > news:hAd81130DHA.1640@S15147418...
> >
> >>Georg Lorrig wrote:
> >>
> >>
> >>>Hello,
> >>>
> >>>at the moment I organize my projects this way:
> >>>
> >>>/proja           ---> includes dll, exe and dbf
> >>>/proja/source    ---> include all source, obj etc.
> >>>
> >>>In the project.xpj I normally refer to
> >>>
> >>>[projext.xpj]
> >>>.\pgm.exe                      <- Attention!!!
> >>>[..\pgm.exe]
> >>>sourcea.prg
> >>>sourceb.prg
> >>
> >>Must be:
> >>
> >>[projext.xpj]
> >>   ..\pgm.exe
> >>
> >>[..\pgm.exe]
> >>   sourcea.prg
> >>   sourceb.prg
> >>
> >>
> >>
> >>>This worked fine with Xbase++ since ever (as far is I remember).
> >>>
> >>>VXbase doesn't get the idea.
> >>>
> >>>I set up a new project in /proja/source (using /proja/source/pgm.exe).
> >>>I remove the default main.prg and "add existing files". Everything is
> >>>fine. If I change the properties of pgm.exe to "..\pgm.exe", all source
> >>>code files are dropped, and there's no way to turn it back.
> >>
> >>This one is currently broken and will be fixed for next release of
> >>PreRelease that will be available soon.
> >>
> >>Regards
> >>   Andreas Herdt
> >>   [Alaska Research & Development]
> >>
> >>
> >>>I think this behaviour is worth a PDR ...
> >>>
> >>>This leads me to the question: how do you handle the separation of
> >>>source and executable?
> >>>
> >>>
> >>>Kind regards,
> >>>
> >>>Georg S. Lorrig
> >>>
> >>
> >
> >
>

Thanks for the info.
As I have stated we will go as I have described
(separation between build and deployment).
However, we have to come back to this issue when VX is customizable
to the extand we are focusing to.
How ever it is allways good to know what scenarios exist in real life.

Regards
   Andreas Herdt
   [Alaska Research & Development]

Luciano wrote:
> Hello Andreas,
> 
> Thanks for your comments, they are very good.
> 
> The complex scenario that we have is using the pbuild with the alaska
> version 1.82
> already. Since the initial xbase++ version we are using the pbuild PLUS OUR
> OWN TOOL
> like a rmake to create a .bat and to update the .xpj as necessary. If you
> want, i can send you
> an example of our .bat and .xpj in order that you can see how much we have
> reached
> using the curren pbuild options and probably you can give us tips to do it
> better or
> you can consider this complex environment for a future release of VX.
> 
> We do not separate modules by developers, we separate modules according to
> the functionality that implements, for example: basic functions, general
> functions,
> sql database access, functions to print documents, maintenance, clients,
> accounts,
> etc... More than one developer can work on the same module at the same time
> (by the way, we are using Microsoft Visual SourceSafe to control the source
> code).
> But all developers create all modules during the compile and link process in
> their
> own local developing environment.
> 
> We are trying to use the Xbase++ as much as posible and it could be great
> if the VX give as the possibility to delete our own tools if the VX can
> support the same and better.
> 
> What do think ? Thanks in advance.
> 
> Regards
> Luciano
> 
> 
> "Andreas Herdt" <andreas.herdt@alaska-research.com> wrote in message
> news:0ymDNqD1DHA.3616@S15147418...
> 
>>Luciano wrote:
>>
>>Well, what you have is a quiet complex scenario.
>>unfortunatly we can not support such a complex
>>scenario with next release. But I think I can give a solution
>>for your problem.
>>
>>First of all, what you describe was not possible with
>>pbuild up to now. It does not provide the seperation
>>of DLL, EXE and OBJ, DEF, EXP, LIB.
>>Nevertheless we allready have on our todo to give the
>>developers a way to distinguish between source files
>>and target files. You can get an idea with OBJ_DIR.
>>Here you can tell pbuild where to build the objects,
>>and from where to take them for linkage.
>>Our plan is to provide a TARGET_DIR to tell pbuild
>>where to build the output files to (exp, libs, dll, exe...)
>>This does currently work with EXE and DLL files, means
>>that the linker places them to TARGET_DIR.
>>(This is currently broken since VX does not know anything
>>about TARGET_DIR)
>>
>>To your problem. As far as I can see you are doing the following:
>>Each developmer works on a module that relies on modules from
>>other developers. The dlls on which the developer depends is
>>taken from the directory where it is built to.
>>
>>I would suggest:
>>Seperate build and deployment. This means that each developer
>>builds its modules. After this is done, the modules are copied
>>to a directory from which other developers take them for their own
>>work:
>>
>>/source/dev1/               <- prg, xpj (first developer)
>>/source/dev2/               <- prg, xpj (second developer)
>>
>>/bin                        <- dll, exe
>>
>>The idea is that in dev1 and dev2 the devs can work independant.
>>After they have built the dlls, they are copied to /bin.
>>/bin is part of the environment variable PATH. In case
>>a DLL is needed, just request it and it will be automatically
>>taken from /bin.
>>
>>We allready have added the POST_ACTION to pbuild.
>>   POST_ACTION = Copy my.dll my.lib my.obj \bin
>>will deploy the files as required.
>>
>>Hope this helps and gives an overview into which direction
>>we are going to go.
>>
>>
>>Regards
>>
>>   Andreas Herdt
>>   [Alaska Research & Development]
>>
>>
>>>Hello Andreas,
>>>
>>>we use a little more complex directory structure:
>>>
>>>a) generated parts from compiler and linker
>>>/proja/bin --> dll and exe
>>>/proja/obj --> obj, def, exp, lib
>>>
>>>b) developed parts (source code .prg and .ch used with the editor)
>>>/source/prg/part1 -->first part of prg files (according to the module 1)
>>>.....
>>>/source/prg/partn -->n part of prg files (according to the module n)
>>>/source/prg/include --> .ch files
>>>
>>>For each developed part we have separated .xpj files that produce .dll
> 
> files
> 
>>>(only one of them
>>>produce the main.exe file).
>>>For example:
>>>part1.xpj produces part1.dll
>>>part2.xpj produces part2.dll (that makes a reference to the produced
>>>part1.lib and part1.dll)
>>>part3.xpj produces part3.dll (that makes a reference to the produced
> 
> part1
> 
>>>and part2 .lib and .dll)
>>>...
>>>partn.xpj produces main.exe that makes reference to all previous
> 
> generated
> 
>>>.dll and .lib files.
>>>
>>>Will be possible to reprodue this enviroment in the next release of the
>>>prerelease ?
>>>I have already tried but in the current version that i downloaded today
> 
> is
> 
>>>not possible.
>>>
>>>This separation of around 12 dll and 1 exe files is necesary because the
>>>size of the application
>>>is too big, around 13 MB (so we have aprox. dlls from 300 KB to 15 MB
> 
> and
> 
>>>the exe is 80 KB)
>>>
>>>What is your opinion ?
>>>
>>>Regards
>>>Luciano
>>>
>>>
>>>
>>>
>>>"Andreas Herdt" <andreas.herdt@alaska-research.com> wrote in message
>>>news:hAd81130DHA.1640@S15147418...
>>>
>>>
>>>>Georg Lorrig wrote:
>>>>
>>>>
>>>>
>>>>>Hello,
>>>>>
>>>>>at the moment I organize my projects this way:
>>>>>
>>>>>/proja           ---> includes dll, exe and dbf
>>>>>/proja/source    ---> include all source, obj etc.
>>>>>
>>>>>In the project.xpj I normally refer to
>>>>>
>>>>>[projext.xpj]
>>>>>.\pgm.exe                      <- Attention!!!
>>>>>[..\pgm.exe]
>>>>>sourcea.prg
>>>>>sourceb.prg
>>>>
>>>>Must be:
>>>>
>>>>[projext.xpj]
>>>>  ..\pgm.exe
>>>>
>>>>[..\pgm.exe]
>>>>  sourcea.prg
>>>>  sourceb.prg
>>>>
>>>>
>>>>
>>>>
>>>>>This worked fine with Xbase++ since ever (as far is I remember).
>>>>>
>>>>>VXbase doesn't get the idea.
>>>>>
>>>>>I set up a new project in /proja/source (using /proja/source/pgm.exe).
>>>>>I remove the default main.prg and "add existing files". Everything is
>>>>>fine. If I change the properties of pgm.exe to "..\pgm.exe", all source
>>>>>code files are dropped, and there's no way to turn it back.
>>>>
>>>>This one is currently broken and will be fixed for next release of
>>>>PreRelease that will be available soon.
>>>>
>>>>Regards
>>>>  Andreas Herdt
>>>>  [Alaska Research & Development]
>>>>
>>>>
>>>>
>>>>>I think this behaviour is worth a PDR ...
>>>>>
>>>>>This leads me to the question: how do you handle the separation of
>>>>>source and executable?
>>>>>
>>>>>
>>>>>Kind regards,
>>>>>
>>>>>Georg S. Lorrig
>>>>>
>>>>
>>>
> 
>

Hello
I think we need an environment setting for a project.
Regards.
CL

Christian Laborde wrote:

> Hello
> I think we need an environment setting for a project.
> Regards.
> CL
> 

Can you explain it a little bit more?

Andreas Herdt
[Alaska Research & Development]

Andreas Herdt,
> Christian Laborde wrote:
> 
>> Hello
>> I think we need an environment setting for a project.
>> Regards.
>> CL
>> 
> 
> Can you explain it a little bit more?
> 
> Andreas Herdt
> [Alaska Research & Development]

VX_PROJECT=c:\projects\thisProj                ; project dir
VX_PROJ_INCLUDE=c:\projects\thisProj\include   ; project specific include
VX_PROJ_OBJ=c:\projects\thisProj\obj           ; project obj dir

etc.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Now, where did I put that dweeb filter?

Yes as there is global environment setting, we must be able to override 
this by a project environment setting with global value by default.
Regards.
CL

Phil Ide wrote:
> Andreas Herdt,
> 
>>Christian Laborde wrote:
>>
>>
>>>Hello
>>>I think we need an environment setting for a project.
>>>Regards.
>>>CL
>>>
>>
>>Can you explain it a little bit more?
>>
>>Andreas Herdt
>>[Alaska Research & Development]
> 
> 
> VX_PROJECT=c:\projects\thisProj                ; project dir
> VX_PROJ_INCLUDE=c:\projects\thisProj\include   ; project specific include
> VX_PROJ_OBJ=c:\projects\thisProj\obj           ; project obj dir

I see....

I have allready explained my thoughts about this in another thread:
OBJ_DIR    (*obj)         <- must be different for debug and nondebug
TARGET_DIR (def, exp, lib)<- must be different for debug and nondebug

Something new here is:

INCLUDE_DIR
BIN_DIR
LIB_DIR

By default they would be filled with the current environment and
then can be modified accordingly. All this would be
project specific or target specific and the tools would be invoked with 
these settings.

Nice idea.

Did I get it?


> etc.
> 
> Regards,

Andreas,

>> VX_PROJECT=c:\projects\thisProj                ; project dir
>> VX_PROJ_INCLUDE=c:\projects\thisProj\include   ; project specific include
>> VX_PROJ_OBJ=c:\projects\thisProj\obj           ; project obj dir
> 
> I see....
> 
> I have allready explained my thoughts about this in another thread:

Yup, I was only trying to demonstrate what was meant.

> Something new here is:
> 
> INCLUDE_DIR
> BIN_DIR
> LIB_DIR
> 
> By default they would be filled with the current environment and
> then can be modified accordingly. All this would be
> project specific or target specific and the tools would be invoked with 
> these settings.
> 
> Nice idea.
> 
> Did I get it?

All the way!

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Fatal error in LIFE.SYS: Deleting sysop.