[gentoo-soc] Ebuild generator week 10 update

[gentoo-soc] Ebuild generator week 10 update

[darkdefende]

Last week I worked some more on the autoconf problem that I'm having for
my ebuild generator.
I didn't get too far and got kinda stuck. So I instead went ahead and
Got my next milestone done:
Be able to figure out deps that is not installed on the system.

I did it with the help of pfl and their web interface. So now I can
check what package files belongs to that are not installed on the
system.
So far I've only done this for header files. But it shouldn't be hard to
have it check for other files also. And because of pfl I can also check
for what versions of the package that the files get's installed with.
So I can later create deps in ebuilds that specifies min/max package
version!

Because I have the pfl stuff implemented I think I can extend the
previous milestone that is autotools support. I hope I can say that I'm
still on schedule because of that.
If not autotools is a really essential feature for the ebuild generator
so I will not drop that to work on other stuff as the ebuild generator
would be quite useless then…

Because GSoC is comming to an end soon I think I will first solve the
autoconf problems that I'm having by trying to ignore/work around most
of the problematic stuff so it can at least generate an ebuild for
autotools projects. I really want to have atleast something working by
the end of this GSoC so I think I'll do a basic solution first then
improve it.

Re: [gentoo-soc] Ebuild generator week 10 update

[Fabian Groffen]

On 25-07-2011 13:02:16 +0200, darkdefende@gmail.com wrote:
> Because I have the pfl stuff implemented I think I can extend the
> previous milestone that is autotools support. I hope I can say that I'm
> still on schedule because of that.
> If not autotools is a really essential feature for the ebuild generator
> so I will not drop that to work on other stuff as the ebuild generator
> would be quite useless then…
> 
> Because GSoC is comming to an end soon I think I will first solve the
> autoconf problems that I'm having by trying to ignore/work around most
> of the problematic stuff so it can at least generate an ebuild for
> autotools projects. I really want to have atleast something working by
> the end of this GSoC so I think I'll do a basic solution first then
> improve it.

Hey,

Because you seem to be stuck here, I'll give you some of my thoughts.
First off, I'll start by saying that none of my ideas is 100%
water-proof for all cases, but they give some start, if not some handle
to have something going, quickly.

Starting with heuristics, I see that some grepping is going to result in
some information that we might be interested in here from configure.

% ./configure --help | grep -E -- '--(with|without)-'

This gives a list of --with/--without that already might give you a good
hint or two.  "--with-gpgme[=PFX]" for example, probably needs a
USE=gpg.  Assume you can map a fair bunch of names to packages.

% grep -E "checking for [^ ]+ in -l.+\.\.\." configure

This returns all libs that configure is checking for.  If you can map
the libs on packages, you can match this with the optional list of
above, probably this is where USE-flags are necessary.  Other libs (one
typically sees -lz in the list) probably need to be unconditional
dependencies.

% grep -E -- "FLAGS=.*-(I|L)" configure

What is returned usually is a big and ugly list.  I doubt it is very
useful, but with some brute force case-insensitive grepping package
names may be found in variables or path names.  The found packages can
be optional or mandatory.  I expect a big overlap with the lib search
before.

I can imagine a pkg-config check (it's an autoconf macro
PKG_CHECK_EXISTS, see pkg-config(1)) to try and do something similar as
the previous grep.

I think largest problem here is to match what you find onto packages.
With some luck you can match a fair bit, though.

Hope this helps a bit,


-- 
Fabian Groffen
Gentoo on a different level