Re: How do I inhibit the copying of the source files to the build tree

[david . weidenkopf]

Hi Timothee,

Your proposal is not really feasible, since the developer wants to be able to checkin/checkout from DevStudio. Ci/Co can only occur in the true source directory. I suppose some sort of rube-goldberg apparatus could be developed to account for the link'ed tree, but we are trying to avoid that. 

Thanks for the idea though
David

Timothee Besset <address@hidden> Sent by: address@hidden 03/15/2002 07:54 AM

To:        address@hidden         cc:        (bcc: David Weidenkopf/ATL-BTL/MS/PHILIPS)         Subject:        Re: How do I inhibit the copying of the source files to the build tree         Classification:

What happens if you just open the .dsp that's in the Linked tree directly?
(probably that cons doesn't copy it by default, but you can tell it to or
something)

You have to map the VC build commands correctly so that compiling will
still work as usual, and your build messages + the files you modify will
be all good?

TTimo

On Fri, 15 Mar 2002 09:47:22 -0600 (CST)
Steven Knight <address@hidden> wrote:

> > We have a couple of issues that arrise out of Cons behavior where all
> > the source files are copied to a separate build tree:
> >
> > By way of background, we are setting up a Cons build to replace an MS
> > DevStudio based build.
> > 1. Double clicking on error messages in the output window, to edit the
> > source files, does not work well when doing a Cons build from within
> > DevStudio.
> 
> This is unfortunately true.  My understanding (I'm not very conversant
> with DevStudio) is that you get the build copy, not the original source
> file, which means any changes you may make can get blown away by the
> next build if you don't notice the difference.
> 
> > 2. Debugging from a Cons build does not make DevStudio very happy.
> > When debugging you are not seeing the file from source tree, rather
> > you are seeing the "link"ed copy of it. Devstudio does not care about
> > htis, but it confuses the developer.  I am curious why we would be the
> > first group to encounter this and think it was not good.  Is the real
> > question "How can we support variant builds without using the "link"
> > command?"
> 
> Probably the best way would be to roll the logic yourself.  Explicitly
> compile your objects and executables in one or more separate variant
> directories, leaving the source files in their original locations.
> 
>                  @sources = ( 'src/f1.c', 'src/f2.c' );
>                  $env->Program('variant1/foo', @sources);
>                  $env->Program('variant2/foo', @sources);
> 
> (Actually, you'd probably have to do it explicitly via Objects calls so
> that the object files end up in the variant build directory, too...)
> 
> > One possible solution for these problems would be to completely
> > inhibit Cons from copying the source to the build tree.  Is this
> > possible?
> 
> Unfortunately, this isn't possible with the Cons implementation of the
> Link() method.  (At the risk of being considered off-topic:  SCons
> does support the ability to build in a variant directory without
> linking/copying in the source files.)
> 
>                  --SK
> 
> 
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/
> 

_______________________________________________
address@hidden
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/