RE: nasm support?

[Gary Oberbrunner]

What I would do (don't know if this is "right" or not...) is define a
CompileNASM method (call it what you want), and then you can swap out the
implementation of that however you like.  I.e. in your Conscripts you'll
have
  $env->CompileNASM(@nasm_files);
(or however they work -- maybe you need to specify destinations, or maybe it
returns objects, or whatever.)

Then you can write
sub cons::CompileNASM
{
  my $env = shift;
  my @nasmfiles = @_;
  foreach my $f (@nasmfiles) {
    $env->Command(....);
  }
}

So that later if there's a more automatic way to do it with Objects,
Program, Library or whatever, you can just swap out this implementation.

I know you'd like to avoid this step, but AFAIK it can't be done yet.  The
refactoring currently being discussed should be able to handle this easily
though.

-- Gary Oberbrunner

 > -----Original Message-----
 > From: address@hidden [mailto:address@hidden
 > Behalf Of Timothee Besset
 > Sent: Wednesday, September 12, 2001 5:56 AM
 > To: address@hidden
 > Subject: nasm support?
 >
 >
 > I am starting to convert some more projects to use cons after
 > the great experience I've had with it on GtkRadiant build
 > system. I have a bunch of .nasm files in this new project. I
 > think that my first approach will be to hardcode their
 > compilation, but in the long run I would like to be able to just
 > give the file.nasm to any 'Program' or 'Library' method.
 >
 > Does anyone have experience with .nasm files / integrated them
 > with cons etc.? Or has info on how I should go about it? (I can
 > write some perl, but I'm not that good at it .. kind of "hello
 > world" stage right now)
 >
 > TTimo
 >
 > _______________________________________________
 > address@hidden
 > http://mail.gnu.org/mailman/listinfo/cons-discuss
 > Cons URL: http://www.dsmit.com/cons/
 >