Re: Construct file extension

[Steven Knight]

> > I think there's an even more important reason to have a different
> > extension (.cons).  Even though the Construct file is a Perl script, you
> > *don't* want it executed directly by Perl.  You want to register that
> > cons.bat or cons.pl execute it.
> 
> I don't understand what you mean by the last sentence above.
> (but I agree that we should avoid ".pl")
> 
> Why would you want to do anything other than:
> 
>     C:\some\dir> cons foo.exe
> 
> What's the point of associating a program like "cons.bat" or
> "cons.pl" with a Construct file ?
> 
> 1) You can't "click" on the Construct file in a GUI, since you
> normally have to supply arguments to cons also (beside the
> "implicit"  Construct file itself).

Sure you can, given the Default() method.  At least, I can't think
of why you shouldn't be able to.  I agree that you can't supply any
arguments to build anything *but* the Default() via a click.

> > > - Cons work as before, icon and extension set or not
> > > - In the environment we add CONS_EXTENSION=.whatever_you_like
> > > - each one fixes the icon problem on his own
> > >
> > > A last problem:
> > > Not having a standard extension makes sharing of construct files harder
> > > (well typing a -f construct.yae harder). The solution is:
> > >
> > > CONS_EXTENSION=.whatever_you_like, .whatever_the_other_guy_likes
> >
> > Sounds good.
> 
> I have to disagree again.
> I do *not* think that an extension for Construct files should be
> configurable. As Nadim mentioned this would "make sharing of
> construct files harder". I think this is a very strong argument
> against a configurable extension.

Good point.

> If anything should be done at all to this extension-issue
> I think it should be as Steven wrote in his first reply:
> 
> > [...] I'd be willing to integrate a change that would looks for
> > Construct.xxx as well as Construct.

Okay, since 4-character extensions appear to be scarce, I'll go with
just coding it to look for Construct.cons.

        --SK