Re: [Flex-devel] Pull Request #16

[Will E. <wes...@gm...>]

On Sunday,  8 November 2015,  1:35 am -0500, Mighty Jo <mig...@gm...> wrote:

> On Sat, Nov 7, 2015 at 4:04 PM, Will Estes <wes...@gm...> wrote:
> 
> > > Make all & check weren't rebuilding all of the scanners in tests/ when
> > > files in src/, skel.c for example, had changed. Several of the tests'
> > built

the test suite tests the built version of flex in the build tree. So, in the case where flex source files change but flex has not been rebuilt, the correct thing to do is to test using the currently built version of flex. The test suit should consider "flex" as a black box that has to be tested.

> > > sources weren't listed as such and 'make clean' didn't reach them so I
> > kept
> > > having to delete them manually or touch the .l's to rebuild them.  I made
> > > sure they were all listed in the right automake vars to let make clean
> > > them.  I didn't fiddle with making them depend on skel.c yet.

I'll look for the patch on this. If you're correct, then it's definitely a bug.

> >
> > Oh, sorting out dependencies, that's different--and awesome. Thanks.
> > That's likely an easy change to incorporate by the way.
> >
> 
> Haha, that's what I was thinking.  I'll still work on separating out the
> change set.  I need the practice with Git.

Branches are your friend ;) Ping me if you need help on this.

> 
> 
> > As for depending on skel.c, that's a generated file, so you probably want
> > to list the dependencies of skel.c instead.
> >
> 
> Cool, that was going to be my question to the mailing list.  I'm always
> back and forth about how to handle this for tests in my own projects.

See above for my thoughts on testing.

> 
> 
> > Regarding c++, how widespread is c++11? Or what constraint does that imply
> > about compiler version or whatever the right way to ask that question is.
> > Is it easy to offer alternatives in a nicely ifdef-y way that would play
> > well with autoconf? You mentioned delegating certain methods and c++ is not
> > something I know more than the rudiments about.
> 
> 
> Delegating is just a fancy name for wrapper functions that change the
> argument types.  C++ handles them just like C does except when the function
> is a constructor.  Then GCC (v5.2.1) gives the error "delegating
> constructors only available with -std=c++11..."  The standard specifies the
> timing of object initialization such that delegated constructors would only
> work if they were lambda closures  - which C++ didn't have until C++11,
> Q.E.D.  It's common practice to work around that with an init method (which
> the optimizer usually inlines) but I prefer the wrapper construction
> aesthetically.  Still, I hate duplicating code worse than excess syntax, so
> I'll deal with it.
> 
> As for c++11, it's well supported on desktop and server targets (x86, x64,
> ppc, etc.) but not as well for embedded targets.  GCC's had good support
> since about v4.8, Visual C++ since 2013, CLANG since v3.3.  But Arduino
> support is still in beta, for example.  The autoconf archive provides
> ax_cxx_compile_stdcxx_11.m4 for the c++11 feature test.  I've used it and
> it works well if we want to go that route.

I'm becoming more a fan of the autoconf archive, yes. That being said, this sort of discussion should be on list so others can weigh in as they have expertise and so google can tape the show for the future.

-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex