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

Creating dependancies with remote objects

My question is somewhat related to the one recently discussed in
the 'inhibit copying' thread...

I was having similar issues with the way 'Link' was linking source
files around...  I had managed to get xemacs to do the right thing
with the links, but it struck me as a messy way to do things...  At
least partially because I lost an hour or so of work by changing the
wrong files in xemacs (before I fixed it), and having the links
remade.  <sigh>

So I independantly came up with a solution similar to the ObjectsInDir
method that Johan discussed in his thread of last June (I called it
RemoteObjects, the behaviour was the same - works like Objects, but
puts the output files in a different directory).

The part of the solution that I'm not too happy with is getting a
dependancy from the source directory to the output files.  The issue
is that since there are no files in the source directory than depend
on anything - doing a 'cons -t .' in the source directory results in
absolutely nothing happening...  Doing a 'cons .' in the root
directory works, and so does 'cons path/to/objects_or_libs', but when
using xemacs' compile mode, it's much easier to just do a 'cons -t .'

The hack that I have figured out that works, but is fairly ugly, is to
add something like

   Command $lenv  "$localdir/dummy", $LIB, "touch %>";

Where $localdir is the directory containing the source, and $LIB is
the library generated from the source... This is moderately functional
(and if I add the target system name into the name of the dummy file
will probably even handle multiple platforms.  But it seems clunky.

Does anyone have any better suggestions?  Have I framed the problem
clearly enough?  Or should I construct a sample directory that
illustrates the issue?

Thanks,

Warren

_______________________________________________
Cons-discuss <at> gnu.org
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/

Re: Creating dependancies with remote objects

On Tue, 26 Mar 2002 Warren_Baird <at> cimmetry.com wrote:
>
> The part of the solution that I'm not too happy with is getting a
> dependancy from the source directory to the output files.  The issue
> is that since there are no files in the source directory than depend
> on anything - doing a 'cons -t .' in the source directory results in
> absolutely nothing happening...  Doing a 'cons .' in the root
> directory works, and so does 'cons path/to/objects_or_libs', but when
> using xemacs' compile mode, it's much easier to just do a 'cons -t .'
>

I haven't used the -t option much, but wouldn't it be natural if one
could say something like below ?

       $ cons -t #build
       $ cons -t #.

and have the # imply that the argument is evaluated relative to
the top-directory (after -t traversal). (# works well in tcsh,
but maybe # should be replaced with a better character, so it
doesn't interfere with Bourne shells comment syntax)

I tried to implement this in my copy of Cons, and it was quite
trivial to accomplish (2 lines of changes).

But I'm not familiar with the reasoning behind the current
implementation of the -t option, so I disabled some of the old logic.
( Why does the current implementation refuse to build
anything "above" the directory cons is invoked in, when the -t
option is given ? )

/Johan Holmberg

_______________________________________________
Cons-discuss <at> gnu.org
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/

Clearcase and cons Link woes

I am using cons in conjunction with Clearcase (the source control [file]
system) on a Solaris box.  The Conscript is set up for building multiple
configurations (multiple platforms) by creating cons Links in the source
subdirectories.  Because cons makes sure the source files then appear in the
link directory, and are compiled there, compilation errors are reported
using paths to the link directory and not paths to the original source
directory.  Unfortunately, clearcase does not (at least by default)
understand that these linked files are actually source control files, so an
unwitting developer who tries to fix the problem by checking out the linked
file runs into difficulty.  They have to understand how cons and the
Conscripts work in order to understand how to check out and edit the files -
which is what I am trying to avoid.  I am also trying to avoid changing
clearcase or having to wrap checkout/checkin in special scripts to figure
out what is going on for the developer.

I guess what I think I want (but not necessarily the best solution) is some
way to have cons leave the source files in the original source directory but
compile the object files to the link directory so that platform objects
don't collide.  This is closer to the way Microsoft's DevStudio by default
handles multiple configurations (not that I'm any particular fan of
DevStudio), and is the only reasonable solution I've seen so far.  Is this
feasible?  What problems would there be in having such a feature?

I haven't tried, but I would guess that the problem is even worse for
snapshot views on Windows since there are no true links there - only copies.
With UNIX there might be hope to list where the hard links
come from and follow the trail to find the real source file, although this
is an extra step.

Thanks,
Guy Delamarter

_______________________________________________
Cons-discuss <at> gnu.org
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/

RE: Clearcase and cons Link woes

When I was developing my MSDEV extensions to Cons (which are now
woefully out of date, I realize), the tack I took was to allow cons to
go ahead and link the files into the build directory, but I added an
escape for the %< argument called ":S" that would interpret the path as
the source of the Link, rather than the destination.  That way, when you
compile, the MSDEV compiler uses the source of the link to compile with,
but cons decides to compile it when the destination of the link is out
of date.  The compiler still outputs all results into the "build" tree,
so there's no pollution of the source tree.

The reason for this was so that the user could double-click on an error
in MSDEV, and get the right file (the right file being the source file,
as in your case).

The two relevant modifications were to the CCOM environment variable,
and to the _variant helper function.  I've attached a copy of the ones I
use below.

I hope that helps...

			-Greg.

--
CXXCOM  => '%CXX %CXXFLAGS %_IFLAGS /c %<:S /Fo%>:d\\',
--
# internal routine to process variable options.
# f: return file part
# F: return file part, but strip any suffix
# d: return directory part
# b: return path, but strip any suffix (a.k.a. return basename)
# s: return only the suffix (or an empty string, if no suffix is there)
# a: return the absolute path to the file.
# S: return the absolute path to the source file.
# no option: return path to file
sub _variant {
  my $opt = shift;
  my $tgt = shift;
  my $isrfile = shift;

  if ($opt eq 'f') { return $tgt->{entry}; }
  elsif ($opt eq 'd') { 
    return $isrfile ? $tgt->rfile->{dir}->path : $tgt->{dir}->path;
  }
  elsif ($opt eq 'F') {
    my $subst = $tgt->{entry};
    $subst =~ s/\.[^\.]+$//;
    return $subst;
  }
  elsif ($opt eq 'b') {
    my $subst = $isrfile ? $tgt->rpath : $tgt->path;
    $subst =~ s/\.[^\.]+$//;
    return $subst;
  }
  elsif ($opt eq 's') {
    my $file = $tgt->{entry};
    $file =~ m/(\.[^\.]+)$/;
    return $1;
  }
  elsif ($opt eq 'a') {
    my $cwd = Cwd::cwd();
    my $path = $isrfile ? $tgt->rpath : $tgt->path;
    $cwd .= $main::DIR_SEPARATOR.$path;
    return $cwd;
  }
  elsif ($opt eq 'S') {
    my $cwd = Cwd::cwd();
    $cwd =~ s,$main::DIR_SEP_REGEXP,$main::DIR_SEPARATOR,g;
    $cwd .= $main::DIR_SEPARATOR.$tgt->srcpath;
    return $cwd;
  }
  else {
    my $path = $isrfile ? $tgt->rpath : $tgt->path;
    return $path;
  }
}

_______________________________________________
Cons-discuss <at> gnu.org
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/

Brave GNU World article online

Hi all,

the Brave GNU World article featuring Cons and SCons is online
available at

http://www.gnu.org/brave-gnu-world/issue-37.en.html

just in case someone needs the reference.

Cheers,
Erich

_______________________________________________
Cons-discuss <at> gnu.org
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/

Re: Brave GNU World article online

cons is truly an awesome tool. I've been using it for months on several
projects, and I don't see myself writing a Makefile again. It's only
missing one thing to be perfect though: will any perl guru with cons
knowledge be able to investigate parallel cons, and fix it so that it
works? (see
http://mail.gnu.org/pipermail/cons-discuss/2002-February/001736.html for
all the details).

TTimo

On Sun, 31 Mar 2002 22:02:28 +0200
Erich Waelde <erwaelde <at> ubbnint1.germany.agilent.com> wrote:

> Hi all,
> 
> the Brave GNU World article featuring Cons and SCons is online
> available at
> 
> http://www.gnu.org/brave-gnu-world/issue-37.en.html
> 
> just in case someone needs the reference.
> 
> Cheers,
> Erich
> 
> _______________________________________________
> Cons-discuss <at> gnu.org
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/
> 

_______________________________________________
Cons-discuss <at> gnu.org
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/