Thread: [Flex-devel] Pull Request #16
flex is a tool for generating scanners
Brought to you by:
wlestes
Menu
▾
▴
flex-devel
|
From: Mighty Jo <mig...@gm...> - 2015-11-07 16:43:54
|
All, I have C++-idiomatic stream handing working in a branch even with master@HEAD. I kept the old interface in addition to the new one - the old-style calls just delegate to the new ones. Had to do something unwieldy with the constructors for yyFlexLexer since delegating constructors didn't become part of the standard until C++11 and I didn't want to add that as a dependency. I tweaked the build system along the way to ensure built sources could be cleaned on demand and to give hints to make's dependency tracking. It's a small change, but I'll build on it. -Joe |
|
From: Will E. <wes...@gm...> - 2015-11-07 18:03:01
|
Thanks for your interest. I've got this in my queue to review. > I tweaked the build system along the way to ensure built sources could be > cleaned on demand and to give hints to make's dependency tracking. How does this effect the automake/autoconf/libtool stuff? In what ways were the features you list missing? > > It's a small change, but I'll build on it. In general, the best practice is to segregate these sorts of changes. So, the c++ stuff and the build system should be two separate pull requests so that they can be handled independently--given that maybe one needs to be handled before the other, especially if one of your change sets assumes the existence of the other. Thanks! --Will On Saturday, 7 November 2015, 11:43 am -0500, Mighty Jo <mig...@gm...> wrote: > All, > > I have C++-idiomatic stream handing working in a branch even with > master@HEAD. I kept the old interface in addition to the new one - the > old-style calls just delegate to the new ones. Had to do something > unwieldy with the constructors for yyFlexLexer since delegating > constructors didn't become part of the standard until C++11 and I didn't > want to add that as a dependency. > > I tweaked the build system along the way to ensure built sources could be > cleaned on demand and to give hints to make's dependency tracking. > > It's a small change, but I'll build on it. a> > -Joe > ------------------------------------------------------------------------------ > _______________________________________________ > Flex-devel mailing list > Fle...@li... > https://lists.sourceforge.net/lists/listinfo/flex-devel -- Will Estes Flex Project Maintainer wes...@gm... https://github.com/westes/flex |
|
From: Mighty Jo <mig...@gm...> - 2015-11-07 20:13:00
|
> > I tweaked the build system along the way to ensure built sources could be > > cleaned on demand and to give hints to make's dependency tracking. > > How does this effect the automake/autoconf/libtool stuff? In what ways were the features you list missing? > 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 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. > > > > It's a small change, but I'll build on it. > > In general, the best practice is to segregate these sorts of changes. So, the c++ stuff and the build system should be two separate pull requests so that they can be handled independently--given that maybe one needs to be handled before the other, especially if one of your change sets assumes the existence of the other. You're right, of course. I got lazy. I'll look at how to divide the changes up cleanly this weekend and put in two fresh requests. > Thanks! You're welcome! I'm glad this is a living project. -Joe |
|
From: Will E. <wes...@gm...> - 2015-11-08 16:04:51
|
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 |
|
From: Mighty Jo <mig...@gm...> - 2015-11-10 02:51:51
|
On Sun, Nov 8, 2015 at 11:04 AM, 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. > Got it. I usually end up building libtool convenience libraries and making my tests depend on those. Depending on the build binary does the same thing in this case. Nifty. I've submitted PR#19 that does just that. > > > > > 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. > > That was PR#18 for the google record. > > > > > > 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. > > Figured it out. Git is much better about this kind of thing than SVN. Love the squash and fixup options when rebasing. <snip> > > 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. It's certainly better than the macros I write myself. > 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. > > Cool beans! -Joe |
|
From: Will E. <wes...@gm...> - 2015-11-10 13:03:16
|
On Monday, 9 November 2015, 9:51 pm -0500, Mighty Jo <mig...@gm...> wrote: > > > 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. > > > It's certainly better than the macros I write myself. So we'll get to this, but only after that next release happens--just because I'll need time to play with the new autoconf bits. There's one or two other things I'd like to add in terms of autoconf magic as well, so I'm thinking "I'd rather do it right". -- Will Estes wes...@gm... |
|
From: Mighty Jo <mig...@gm...> - 2015-11-10 13:11:35
|
On Nov 10, 2015 8:03 AM, "Will Estes" <wes...@gm...> wrote: > > > > 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. > > > > > > It's certainly better than the macros I write myself. > > So we'll get to this, but only after that next release happens--just because I'll need time to play with the new autoconf bits. There's one or two other things I'd like to add in terms of autoconf magic as well, so I'm thinking "I'd rather do it right". Certainly. I was thinking this would be a consideration for 3.0 at the earliest. -Joe |
|
From: Will E. <wes...@gm...> - 2015-11-10 13:16:48
|
Yeah, I need to draw up a road map, but that means clearing out the backlog of bugs and patches and feature requests and such first. And then we need some time where the new flex locations are well known and the big operating system vendors have time to catch up to where flex is so we can see what other problems surface. So at the moment, there is no "3.0" plan. On Tuesday, 10 November 2015, 8:11 am -0500, Mighty Jo <mig...@gm...> wrote: > On Nov 10, 2015 8:03 AM, "Will Estes" <wes...@gm...> wrote: > > > > > 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. > > > > > > > > > It's certainly better than the macros I write myself. > > > > So we'll get to this, but only after that next release happens--just > because I'll need time to play with the new autoconf bits. There's one or > two other things I'd like to add in terms of autoconf magic as well, so I'm > thinking "I'd rather do it right". > > Certainly. I was thinking this would be a consideration for 3.0 at the > earliest. > > -Joe > ------------------------------------------------------------------------------ > _______________________________________________ > Flex-devel mailing list > Fle...@li... > https://lists.sourceforge.net/lists/listinfo/flex-devel -- Will Estes wes...@gm... |
|
From: Mighty Jo <mig...@gm...> - 2015-11-10 13:32:42
|
On Nov 10, 2015 8:16 AM, "Will Estes" <wes...@gm...> wrote: > > Yeah, I need to draw up a road map, but that means clearing out the backlog of bugs and patches and feature requests and such first. > > And then we need some time where the new flex locations are well known and the big operating system vendors have time to catch up to where flex is so we can see what other problems surface. > > So at the moment, there is no "3.0" plan. Fair enough. I only use the one feature regularly anyway. No need to introduce a big change just for that. -Joe |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X