[gentoo-soc] Ebuild Generator week 7

[gentoo-soc] Ebuild Generator week 7

[darkdefende]

This week I began to work on implementing support for autotools in my
ebuild generator. I am now on schedule.

The first thing I did this week was to implement a basic automake parser
and I was pleasantly supprised that it was a lot easier to write and
interpret than the vanilla make files.
But that is probably why automake exists in the first place…

I then went on to write a autoconf parser.
That didn't went as smoothly as I wanted as you have to be really
careful in how you parse the files as you can mix in commands that
creates unbalanced parentheses or may screw with your parser in other
ways.
Thankfully they have quotation marks "[]" that you should wrap around
such cases.

Now I'm moving on to figure out how I should structure how the
program searches for possible useflag and/or optional dependecies.

I'm thinking about having it parse the makefile first and look for
variables that configure will supply to it in relevant areas.
Like variables that pull in stuff from EXTRA_…_SOURCES for example.
This way I can look for where those variables are defined in the
autoconf file and then just evaluate those parts of the autoconf file.

I don't know if this will make it easier or save me any time. But it
seems to me like it would be better if I could just evaluate those cases
as they use, as far as I've seen, the same autoconf macros/functions.
Which would mean that I can narrow down which macros I have to
implement.

I would really like some feedback on this as it could be a really really
bad idea.

Re: [gentoo-soc] Ebuild Generator week 7

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

On 22:08 Sun 03 Jul     , darkdefende@gmail.com wrote:
> Now I'm moving on to figure out how I should structure how the program 
> searches for possible useflag and/or optional dependecies.
> 
> I'm thinking about having it parse the makefile first and look for 
> variables that configure will supply to it in relevant areas. Like 
> variables that pull in stuff from EXTRA_…_SOURCES for example. This 
> way I can look for where those variables are defined in the autoconf 
> file and then just evaluate those parts of the autoconf file.
> 
> I don't know if this will make it easier or save me any time. But it 
> seems to me like it would be better if I could just evaluate those 
> cases as they use, as far as I've seen, the same autoconf 
> macros/functions. Which would mean that I can narrow down which macros 
> I have to implement.

I wouldn't do it that way; I would complete ignore the Makefiles on an 
autotools project, since as you've said they are fraught with 
complexity. Generated Makefiles are far more complex than handwritten 
ones, although the nice thing is that if one works, they all do.

I would check AC_ARG_WITH and AC_ARG_ENABLE, which tells you what 
features are truly optional and also give a good idea of what the USE 
flags should be. I'd use those to determine what variables and defines 
get set in an optional way, and then track them through (1) Makefile.am 
files to see how it changes what's built and how and (2) the source 
files themselves to see how it changes #ifdefs and thus what's included.

--
Thanks,
Donnie

Donnie Berkholz
Admin, Summer of Code
Gentoo Linux and X.Org
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-soc] Ebuild Generator week 7

[darkdefende]

Donnie Berkholz writes:

> I wouldn't do it that way; I would complete ignore the Makefiles on an
> autotools project, since as you've said they are fraught with
> complexity. Generated Makefiles are far more complex than handwritten
> ones, although the nice thing is that if one works, they all do.
>
My bad, I meant the Makefile.am files ofcourse.

> I would check AC_ARG_WITH and AC_ARG_ENABLE, which tells you what
> features are truly optional and also give a good idea of what the USE
> flags should be. I'd use those to determine what variables and defines
> get set in an optional way, and then track them through (1) Makefile.am
> files to see how it changes what's built and how and (2) the source
> files themselves to see how it changes #ifdefs and thus what's included.
>
Sounds good, I'll do it that way then! :)