Alaska Software Inc. - Opening an existing Project
Username: Password:
AuthorTopic: Opening an existing Project
Joe CarrickOpening an existing Project
on Wed, 24 Dec 2003 09:53:56 -0800
I find that when an existing project is opened, many files are listed below
the "prg's", including "obj", "arc", "res", and "ch".

If I try to open the "ch" files I get a notice that the file can not be
opened ( it looks for the file in the project folder ).
I remove all such listings except "arc".  IMO, they shouldn't be there in
the first place.

When I rebuild the project, these files do not re-appear in the listing, so
I assume I'm right that they shouldn't be there in the first place.

The "ch" files listed in the "include" folder of the Project Manager are
opened from their location as specified in the "INCLUDE" Environment
Variable.  That's as it should be, and a welcome feature.

-Joe
Joe CarrickClarification
on Wed, 24 Dec 2003 09:57:37 -0800
This only happens the first time an existing Xbase++ project is opened in
VX.

Once the corrections have been made, the existing project file can be opened
without the files being listed improperly.

-Joe
James Loughner Re: Clarification
on Wed, 24 Dec 2003 13:49:41 -0500
Joe this maybe due to how your original Project.xpj file is written. 
There are apperrently some differences. And things that the old build 
would allow may not be allowed in the new one.

Jim

Joe Carrick wrote:
> This only happens the first time an existing Xbase++ project is opened in
> VX.
> 
> Once the corrections have been made, the existing project file can be opened
> without the files being listed improperly.
> 
> -Joe
> 
>
Joe CarrickRe: Clarification
on Wed, 24 Dec 2003 11:20:53 -0800
Hi Jim,

I will check, but these projects were created strictly according to the
rules indicated in the Alaska guidelines for VX.

-Joe

"James Loughner" <jwrl@charter.net> wrote in message
news:hGx3P8kyDHA.1972@S15147418...
> Joe this maybe due to how your original Project.xpj file is written.
> There are apperrently some differences. And things that the old build
> would allow may not be allowed in the new one.
>
> Jim
>
> Joe Carrick wrote:
> > This only happens the first time an existing Xbase++ project is opened
in
> > VX.
> >
> > Once the corrections have been made, the existing project file can be
opened
> > without the files being listed improperly.
> >
> > -Joe
> >
> >
>
Kai FroebRe: Clarification
on Wed, 24 Dec 2003 21:05:00 +0100
Joe,
it will help, when you send in your original xpj file.
The original xpj file is preserved (with the extension xpj.VX_20_BAK)
HTH and merry chrismas
Kai


Joe Carrick wrote:
> Hi Jim,
>
> I will check, but these projects were created strictly according to
> the rules indicated in the Alaska guidelines for VX.
>
> -Joe
>
> "James Loughner" <jwrl@charter.net> wrote in message
> news:hGx3P8kyDHA.1972@S15147418...
>> Joe this maybe due to how your original Project.xpj file is written.
>> There are apperrently some differences. And things that the old build
>> would allow may not be allowed in the new one.
>>
>> Jim
>>
>> Joe Carrick wrote:
>>> This only happens the first time an existing Xbase++ project is
>>> opened in VX.
>>>
>>> Once the corrections have been made, the existing project file can
>>> be opened without the files being listed improperly.
>>>
>>> -Joe
Joe Carrick - The ManiaccRe: Clarification
on Wed, 24 Dec 2003 13:00:12 -0800
Hi Kai,

I have attached both the XPJ and the VX_20_BAK files.  I also used pbuild to
create a newer version of the original.  It seems that the difference is in
the order of the AutoDepend section.  If the OBJ's preceed the CH files,
then VX creates a properly modified XPJ.  If the CH files are listed first
then the result is the attached XPJ.

IMO, order should not matter.  In fact, I would think that the AutoDepend
section should be stripped and VX should rebuild the dependencies
automatically.

-Joe

"Kai Froeb" <kai@froeb-software.de> wrote in message
news:zVcpKjlyDHA.1972@S15147418...
> Joe,
> it will help, when you send in your original xpj file.
> The original xpj file is preserved (with the extension xpj.VX_20_BAK)
> HTH and merry chrismas
> Kai
>
>
> Joe Carrick wrote:
> > Hi Jim,
> >
> > I will check, but these projects were created strictly according to
> > the rules indicated in the Alaska guidelines for VX.
> >
> > -Joe
> >
> > "James Loughner" <jwrl@charter.net> wrote in message
> > news:hGx3P8kyDHA.1972@S15147418...
> >> Joe this maybe due to how your original Project.xpj file is written.
> >> There are apperrently some differences. And things that the old build
> >> would allow may not be allowed in the new one.
> >>
> >> Jim
> >>
> >> Joe Carrick wrote:
> >>> This only happens the first time an existing Xbase++ project is
> >>> opened in VX.
> >>>
> >>> Once the corrections have been made, the existing project file can
> >>> be opened without the files being listed improperly.
> >>>
> >>> -Joe
>
>






Rulers.XPJ.VX_20_BAK
Rulers.XPJ
Kai FroebRe: Clarification
on Thu, 25 Dec 2003 08:13:04 +0100
Hi Joe,

> IMO, order should not matter.

I agree with you that the order shouldn't matter.

> In fact, I would think that the
> AutoDepend section should be stripped and VX should rebuild the
> dependencies automatically.

Have you tried the two menu items:
- Build - clean project
and
- build - rebuild dependencies?

(I'm not sure about thr differences betwen these two, btw.
However from the naming it seems that one would be wise to first clean
a project before rebuilding dependencies).

HTH and merry chrismas!
Kai

Joe Carrick - The Maniacc wrote:
> Hi Kai,
>
> I have attached both the XPJ and the VX_20_BAK files.  I also used
> pbuild to create a newer version of the original.  It seems that the
> difference is in the order of the AutoDepend section.  If the OBJ's
> preceed the CH files, then VX creates a properly modified XPJ.  If
> the CH files are listed first then the result is the attached XPJ.
>
> IMO, order should not matter.  In fact, I would think that the
> AutoDepend section should be stripped and VX should rebuild the
> dependencies automatically.
>
> -Joe
>
> "Kai Froeb" <kai@froeb-software.de> wrote in message
> news:zVcpKjlyDHA.1972@S15147418...
>> Joe,
>> it will help, when you send in your original xpj file.
>> The original xpj file is preserved (with the extension xpj.VX_20_BAK)
>> HTH and merry chrismas
>> Kai
>>
>>
>> Joe Carrick wrote:
>>> Hi Jim,
>>>
>>> I will check, but these projects were created strictly according to
>>> the rules indicated in the Alaska guidelines for VX.
>>>
>>> -Joe
>>>
>>> "James Loughner" <jwrl@charter.net> wrote in message
>>> news:hGx3P8kyDHA.1972@S15147418...
>>>> Joe this maybe due to how your original Project.xpj file is
>>>> written. There are apperrently some differences. And things that
>>>> the old build would allow may not be allowed in the new one.
>>>>
>>>> Jim
>>>>
>>>> Joe Carrick wrote:
>>>>> This only happens the first time an existing Xbase++ project is
>>>>> opened in VX.
>>>>>
>>>>> Once the corrections have been made, the existing project file can
>>>>> be opened without the files being listed improperly.
>>>>>
>>>>> -Joe
Andreas Herdt Re: Clarification
on Thu, 25 Dec 2003 10:38:28 +0100
Kai Froeb wrote:

>> In fact, I would think that the
>> AutoDepend section should be stripped and VX should rebuild the
>> dependencies automatically.

Negative. Collecting the dependency information is a very time
consuming issue. You can verify this by executing pbuild -g.
On large projects this operation lasts for several seconds.

The problem here is that the dependencys are known from the
compiler only => You know the dependencies after you have
compiled the module. Then you can decide whether to compile
the project/target again.

You are right. This issue has to be handled more intelligent.
With intelligent I mean to invoke another compiler run if it
is necessary, only.

> 
> Have you tried the two menu items:
> - Build - clean project
> and
> - build - rebuild dependencies?
> 
> (I'm not sure about thr differences betwen these two, btw.
> However from the naming it seems that one would be wise to first clean
> a project before rebuilding dependencies).

The difference is that:

clean:       pbuild -c -> remove all target files
rebuild dep: pbuild -g -> recreate dependencies
                          reload resulting xpj back to
                          VX.

> 
> HTH and merry chrismas!
> Kai
> 

Regards


Andreas Herdt


//////////////////////////////////////////////////////////////////
//
// Alaska Research & Development
// Homepage: www.alaska-research.com
// Newsgroup: nntp://news.alaska-Software.net
//
//////////////////////////////////////////////////////////////////
Andreas Herdt Re: Clarification
on Thu, 25 Dec 2003 10:25:22 +0100
Hi Maniacc,

I will try to clearify what happens.

> I find that when an existing project is opened, many files are
> listed below the "prg's", including "obj", "arc", "res", and "ch".

Only such files are listed that are dependencies of the targets and
are not part of the autodepend section. This can be any type of
files (even Microsoft Word files). Double clicking such a file node
will of course make the VX open the file. At this point, the 
Projectmanager does not search any directory for the file.

As a rule of thumb, there should be only source files in the area
after the autodepend section. When building the dependencies the
Xbase++ compiler finds out on what intermediate files like *.obj
and *.res files the module depends. These files go to the auto
depend section. With *.ch files it is the same. The compiler finds
out what files are included. Thus they are part of the autodepend
section.

There is no need to maintain this manually. This would mean to
modify the project file when including a header file with
#include.


> If I try to open the "ch" files I get a notice that the file can
> not be opened ( it looks for the file in the project folder ).
> I remove all such listings except "arc".  IMO, they shouldn't be
> there in the first place.

This is because it is not there. The VX looks in the directory
where the xpj file is.

> When I rebuild the project, these files do not re-appear in the
> listing, so I assume I'm right that they shouldn't be there in
> the first place.

Andreas():alarmMode( .T. )
Please clearify this. We made great efforts that it is assured
that VX does not modify the semantic of the project file.
It should be guaranteed that everything that is read from the
project file is restored again.

> The "ch" files listed in the "include" folder of the Project
> Manager are opened from their location as specified in the
> "INCLUDE" Environment Variable That's as it should be, and a
> welcome feature.

You've got it. Headers and libraries are automatically maintained.
You include a header where ever it is required and VX collects
all headers that are included anywhere in the project.
The same is with Libraries. This is the reason why Libs should be
Module (prg) specific and should be added with the #pragma Library
statement. Then VX knows which lib is required where in the
project.

Andreas():alarmMode( .F. )
Just had another look on the project files that you have sent.
It must be  $START-AUTODEPEND not  $STARTAUTODEPEND

Having seen this, I can understand why VX behaved like you
described.

Regards and Happy VX'ing


Andreas Herdt


//////////////////////////////////////////////////////////////////

 Alaska Research & Development
 Homepage: www.alaska-research.com
 Newsgroup: nntp://news.alaska-Software.net

//////////////////////////////////////////////////////////////////

Joe Carrick - The Maniacc wrote:

> Hi Kai,
> 
> I have attached both the XPJ and the VX_20_BAK files.  I also used pbuild
> to
> create a newer version of the original.  It seems that the difference is
> in
> the order of the AutoDepend section.  If the OBJ's preceed the CH files,
> then VX creates a properly modified XPJ.  If the CH files are listed first
> then the result is the attached XPJ.
> 
> IMO, order should not matter.  In fact, I would think that the AutoDepend
> section should be stripped and VX should rebuild the dependencies
> automatically.
> 
> -Joe
> 
> "Kai Froeb" <kai@froeb-software.de> wrote in message
> news:zVcpKjlyDHA.1972@S15147418...
>> Joe,
>> it will help, when you send in your original xpj file.
>> The original xpj file is preserved (with the extension xpj.VX_20_BAK)
>> HTH and merry chrismas
>> Kai
>>
>>
>> Joe Carrick wrote:
>> > Hi Jim,
>> >
>> > I will check, but these projects were created strictly according to
>> > the rules indicated in the Alaska guidelines for VX.
>> >
>> > -Joe
>> >
>> > "James Loughner" <jwrl@charter.net> wrote in message
>> > news:hGx3P8kyDHA.1972@S15147418...
>> >> Joe this maybe due to how your original Project.xpj file is written.
>> >> There are apperrently some differences. And things that the old build
>> >> would allow may not be allowed in the new one.
>> >>
>> >> Jim
>> >>
>> >> Joe Carrick wrote:
>> >>> This only happens the _first_ time an existing Xbase++ project is
>> >>> opened in VX.
>> >>>
>> >>> Once the corrections have been made, the existing project file can
>> >>> be opened without the files being listed improperly.
>> >>>
>> >>> -Joe
>>
>>
Joe Carrick - The ManiaccRe: Clarification
on Thu, 25 Dec 2003 09:28:08 -0800
Hi Andreas,

"Andreas Herdt" <andreas.herdt@alaska-research.com> wrote in message
news:6sWG8EtyDHA.1976@S15147418...
> Hi Maniacc,
>
>
> Andreas():alarmMode( .F. )
> Just had another look on the project files that you have sent.
> It must be  $START-AUTODEPEND not  $STARTAUTODEPEND
>
> Having seen this, I can understand why VX behaved like you
> described.
>

Oh, I hadn't seen that but you are correct.  This was a project file that
came from another Xbase++ user's download on the NG.  Interestingly, "pbuild
rulers /g" doesn't seem to mind the differnece in syntax.  The fact that the
"-" is missing from both $START-AUTODEPEND and $STOP-AUTODEPEND doesn't seem
to make any difference to pbuild, but VX definitely cares.

-Joe