You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Peter Karman <pe...@peknet.com> on 2011/10/28 06:26:02 UTC
[lucy-dev] C implementation [was Re: [lucy-dev] All dependency licensing issues
resolved]
Marvin Humphrey wrote on 10/27/11 5:31 PM:
> Greets,
>
> A few hours ago, the existing implementation of the Clownfish parser was
> swapped out for one based on Flex and the Lemon parser generator, eliminating
> Lucy's dependency on the CPAN module Parse::RecDescent.
>
> As of today, the Lucy mainline no longer has any non-core Perl dependencies,
> and all of the licensing and legal issues that needed to be resolved during
> Lucy's incubation have been resolved.
>
awesome. really. great work, Marvin.
/me raises toast
With that out of the way, I propose a host language implementation in C to go
along with the existing Perl implementation. I'm volunteering to lead that
effort. I think a C implementation can be useful on its own and as a learning
process for How to Write a Lucy Implementation.
I will happily advocate for a Lucy graduation VOTE once we have another language
complete.
Who's with me?
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Nov 6, 2011, at 8:29 PM, Marvin Humphrey wrote:
> Since the C API is going to be Unix only, the only objection I have to using
> Autoconf is that... it's Autoconf. ;) Have at it!
Why Unix only?
D
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 11/6/11 10:29 PM:
> On Sun, Nov 06, 2011 at 08:42:33PM -0600, Peter Karman wrote:
>> Is there anything to be gained by using autoconf and friends?
>>
>> Or asked another way, why would we *not* want to use autoconf and friends?
>
> Since the C API is going to be Unix only, the only objection I have to using
> Autoconf is that... it's Autoconf. ;) Have at it!
>
> So long as you aren't suggesting *replacing* Charmonizer with Autoconf, we
> have consensus and we can move forward. (If OTOH you want to replace
> Charmonizer with Autoconf, prepare for a long, bloody, morale-sucking battle.)
>
no plan to replace Charmonizer on my part. long, bloody battle averted. :)
ok, based on this and Nate's good observations, I'm hearing consensus and I'll
move forward with autotools.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Nov 06, 2011 at 08:42:33PM -0600, Peter Karman wrote:
> Is there anything to be gained by using autoconf and friends?
>
> Or asked another way, why would we *not* want to use autoconf and friends?
Since the C API is going to be Unix only, the only objection I have to using
Autoconf is that... it's Autoconf. ;) Have at it!
So long as you aren't suggesting *replacing* Charmonizer with Autoconf, we
have consensus and we can move forward. (If OTOH you want to replace
Charmonizer with Autoconf, prepare for a long, bloody, morale-sucking battle.)
> I realize that it duplicates a lot of what charmonizer does.
Doesn't matter so long as we don't rely on it for that. In particular, it
doesn't matter so long as we don't introduce Autoconf into the build process
for Lucy's other host bindings.
> OTOH, automake can generate a fully-featured Makefile like Module::Build
> does for Perl (I know M::B doesn't create a file called 'Makefile' but the
> concept is the same).
I understand what you're getting at. If you're most comfortable using
Autotools for the Unix C bindings, cool by me -- other Unix C devs are also
going to feel comfortable with them.
Marvin Humphrey
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency licensing issues resolved]
Posted by "Andrew S. Townley" <as...@atownley.org>.
On 7 Nov 2011, at 4:13 AM, Nathan Kurz wrote:
> On Sun, Nov 6, 2011 at 6:42 PM, Peter Karman <pe...@peknet.com> wrote:
>> Marvin Humphrey wrote on 10/28/11 1:09 AM:
>>> It may be hard/awkward/impossible to do everything we need with Make. We
>>> still have to run the Clownfish compiler from Perl right now, so when we get
>>> to that, we'll need a Perl script that we can run from Make.
>>
>> Is there anything to be gained by using autoconf and friends?
>>
>> Or asked another way, why would we *not* want to use autoconf and friends?
[snip]
> In the comments, there are a few couple good arguments for CMake as a
> more palatable and portable alternative, but I think the authors are
> right that we will viewed with considerable suspicion and initial
> prejudice by Linux developers if we don't use autoconf for a C
> library.
>
> Strangely, I think it's actually permissible if the actual Makefile
> calls out to Perl and Charmonizer (and to build Charmonizer), but for
> acceptance this should be hidden behind a layer of "configure && make
> && make install".
>
> I'm not sure what the Windows perspective looks like, but I fear it
> might not be compatible with this view. Can any of the new additions
> to this list offer that perspective? And what works well for OSX?
>
> --nate
The only thing I can add is that I've been going through the same questions for a different project and still failed to come up with an answer that I liked. While it's a bit of a mutant, an advantage on OSX is that it will generate an Xcode project (along with MSVC projects), but there are still some issues. I haven't yet made the decision, but having worked with autotools for years on some fairly complex projects, when they work, they do make life a lot simpler than trying to do cross-platform stuff other ways.
Obviously, autotools will work just fine on OSX, but they don't support integration with native applications very well. Anytime you're doing any GUI stuff, you'll have developers using Xcode projects. If there are a lot of source files, adding these to the project manually and getting things working from an autotools build is a bit of a PITA.
Again, I don't have an answer, but I wanted to provide some OSX-centric observations.
Cheers,
ast
--
Andrew S. Townley <as...@atownley.org>
http://atownley.org
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Nathan Kurz <na...@verse.com>.
On Sun, Nov 6, 2011 at 6:42 PM, Peter Karman <pe...@peknet.com> wrote:
> Marvin Humphrey wrote on 10/28/11 1:09 AM:
>> It may be hard/awkward/impossible to do everything we need with Make. We
>> still have to run the Clownfish compiler from Perl right now, so when we get
>> to that, we'll need a Perl script that we can run from Make.
>
> Is there anything to be gained by using autoconf and friends?
>
> Or asked another way, why would we *not* want to use autoconf and friends?
A couple of Linux developers recently came up with a sample library
designed to show best practices:
http://0pointer.de/blog/projects/libabc.html
They take a strong pro-autoconf stance that I think reflects the
current Linux mainstream:
----------------------------------------------------------------------------
use autotools
- every custom config/makefile build system is worse for everybody
than autotools is
- we are all used to autotools, it works, nobody cares
- it's only two simple files to edit and include in git, which are
well understood by many many people, not just you.
- ignore all crap autotools create in the source tree. never check
the created files into git
- Never, ever, ever install config.h. That's internal to your
sources and is nothing to install.
- And really, anything but autotools is not an option. Just get over
it. Everything else is crack, and it will come back to you if you
choose anything else, sooner or later. Why? think cross
compilation, installation/uninstallation, build root integration,
separate object trees, standard adherence, tarball handling, make
distcheck, portability between distros, ...
------------------------------------------------------------------------------
In the comments, there are a few couple good arguments for CMake as a
more palatable and portable alternative, but I think the authors are
right that we will viewed with considerable suspicion and initial
prejudice by Linux developers if we don't use autoconf for a C
library.
Strangely, I think it's actually permissible if the actual Makefile
calls out to Perl and Charmonizer (and to build Charmonizer), but for
acceptance this should be hidden behind a layer of "configure && make
&& make install".
I'm not sure what the Windows perspective looks like, but I fear it
might not be compatible with this view. Can any of the new additions
to this list offer that perspective? And what works well for OSX?
--nate
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 10/28/11 1:09 AM:
> Second task: probably build and run Charmonizer. Basically port
> trunk/ruby/Rakefile to the build language of your choice, which was GNU Make
> if I recall correctly. (The same content is in the Perl build, but alongside
> a lot of other stuff, which is why I suggest working off the Ruby build.)
>
> It may be hard/awkward/impossible to do everything we need with Make. We
> still have to run the Clownfish compiler from Perl right now, so when we get
> to that, we'll need a Perl script that we can run from Make.
Is there anything to be gained by using autoconf and friends?
Or asked another way, why would we *not* want to use autoconf and friends?
I realize that it duplicates a lot of what charmonizer does. OTOH, automake can
generate a fully-featured Makefile like Module::Build does for Perl (I know M::B
doesn't create a file called 'Makefile' but the concept is the same).
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Oct 27, 2011 at 11:26:02PM -0500, Peter Karman wrote:
> /me raises toast
/me quaffs deeply
> With that out of the way, I propose a host language implementation in C to go
> along with the existing Perl implementation. I'm volunteering to lead that
> effort. I think a C implementation can be useful on its own and as a learning
> process for How to Write a Lucy Implementation.
>
> I will happily advocate for a Lucy graduation VOTE once we have another language
> complete.
+1
This will be fun. :) C is an interesting choice for a second language. Lucy
is still designed for OO dynamic languages, and the interface will never feel
exactly like the C from k&r.
> Who's with me?
Huzzah!
First suggestion: start with an svn copy of "trunk/example-lang" to "trunk/c"?
Also, consider screwing up several times to get your commit numbers up,
preferably on line endings so that you get svn blame/credit for every line of
every file after the fix. ;)
Second task: probably build and run Charmonizer. Basically port
trunk/ruby/Rakefile to the build language of your choice, which was GNU Make
if I recall correctly. (The same content is in the Perl build, but alongside
a lot of other stuff, which is why I suggest working off the Ruby build.)
It may be hard/awkward/impossible to do everything we need with Make. We
still have to run the Clownfish compiler from Perl right now, so when we get
to that, we'll need a Perl script that we can run from Make.
Marvin Humphrey
Re: [lucy-dev] C implementation [was Re: [lucy-dev] All dependency
licensing issues resolved]
Posted by Torsten Curdt <tc...@vafer.org>.
> With that out of the way, I propose a host language implementation in C to go
> along with the existing Perl implementation. I'm volunteering to lead that
> effort. I think a C implementation can be useful on its own and as a learning
> process for How to Write a Lucy Implementation.
>
> I will happily advocate for a Lucy graduation VOTE once we have another language
> complete.
>
> Who's with me?
Sounds great!