On 5/17/06, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
On 5/17/06, Carlo Calica <[EMAIL PROTECTED]> wrote:
> On 5/17/06, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> > Talking about dependencies, I'm dealing with situations here where
> > they differ depending on the architecture being compiled. After all,
> > we usually don't want tons of extra features on packages for the
> > embedded.
> >
> I understand why but wouldn't it be confusing?
If we store the dependencies on a different file, I don't think so.
The per-arch recipe already specifies different compile flags in many
cases.
My concern is the maintenance overhead and things going out of sync.
Having *Dependencies files spread around that are 80% similar would be
Not Good. If we're extending the *Dependencies syntax anyway, then why
not have something like this:
Glibc [2.2, )
GTK+ [2.0, )
LibID3Tag [0.15, ) [not arm]
Xorg [6.0, )
PPC-Specific-Stuff [1.0, ) [ppc]
(Didn't think much about the syntax, just lifted it from
http://packages.debian.org/unstable/utils/htop )
BTW, I'm having second thoughts about the "math-interval" way of
specifying ranges. Maybe the plain old ">=" would be more natural
looking, and some books write half-open intervals as "[2,2, [" anyway.
> > What about *Dependencies-$ARCH? That way we can have
> > BuildDependencies-x86, BuildDependencies-ARM, BuildDependencies-MIPS
> > and so on. If no "-$ARCH" file exists, then the existing ones are used
> > for all architectures.
>
> Hmm, $ARCH/Resources/*Dependencies is probably better.
Good, I like that. In that case, will the existence of an
$ARCH/Resources make the global one to be ignored, or should we copy
./Resources/* and then override any dups by copying $ARCH/Resources/*
to the target dir?
> Is there any case where $ARCH/Recipe shouldn't override the base ./Recipe
(or
> other files)?
No, there isn't any. All arch-aware recipes are being carefully
written to not confuse and override the main recipe. Usually, when
there are too much information specific to a given arch on the recipe,
it's just easier to split that among i686/Recipe ppc/Recipe and so on,
leaving the base Recipe cleaner.
I noticed some unnecessary copy-and-paste in the $ARCH/Recipe files; I
don't remember if we already talked about this. Avoid moving non-i686
specific stuff into i686/Recipe just to factor out options between
architectures.
Bad:
i686/Recipe:
configure_options=(
--flag1
--flag2
--flag3
)
ppc/Recipe:
configure_options=(
--flag1
--flag2
--flag3
)
arm/Recipe:
configure_options=(
--flag1
--flag2
--flag3
--flag4-for-arm
)
sh/Recipe:
configure_options=(
--tiny
)
Good:
Recipe:
configure_options=(
--flag1
--flag2
--flag3
)
arm/Recipe:
configure_options=(
"[EMAIL PROTECTED]"
--flag4-for-arm
)
sh/Recipe:
configure_options=(
--tiny
)
-- Hisham
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
