Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Manoj Srivastava <srivasta@debian.org> writes:
> On 18 Jun 2006, Goswin von Brederlow outgrape:
>
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>
>>> Goswin von Brederlow wrote:
>>>> On the other hand the savings can be huge. Think about how many
>>>> packages install latex and fonts and generate the documentation
>>>> needlessly during build. Installing and purging latex as well as
>>>> all the initex runs and font generation takes up a awfull lot of
>>>> time
>>>
>>> I think most packages build their documentation or other
>>> architecture-independent parts as part of a general make/make
>>> install process, so it's not possible to create useful separate
>>> build-arch and build-indep targets.
>>
>> A lot of software has a doc dir and it is relatively simple to
>> seperate recursing into doc from the rest. Unless the build-*
>> targets become actually usefull nobody will put any work into
>> splitting the build process into arch and indep parts though.
>
> Umm. Most of my packages I can simply call "make" or "ake
> build" and let upstream Makefiles build stuff -- which means that if
> the arch indep part is split of changed (./scripts dir, for example),
> I do not have to change my rules file to follow suit. In this case,
> splitting the buiild process into arch and indep parts is not trivial.
I would think "make" will always do the customary "all" and include
docs and such. But what stops you from having a "make binary" to
compile and "make doc" in the Makefile? Yes you need to change the
makefile and debian/rules but it usualy isn't that hard.
>>> Looking at the archive right now, there are only 129 source
>>> packages (in testing) that are not Architecture: all and declare
>>> Build-Depends-Indep (and quite a few of those are obviously wrong).
>>> So it seems to be a limited problem. However, if your concern is
>>> mostly to reduce installation time of documentation tools, then the
>>> current Build-Depends/Build-Depends-Indep setup seems to work quite
>>> well. I don't see where Build-Depends-Arch would fit in there.
>>
>> The problem currently is that it isn't even possible to seperate
>> them even if the makefile suports it because the build target must
>> be called. The proposal is as much a clarification and extension of
>> the Build-Depends* fields as a mechanism to detect and use build-*
>> targets. Only then can one split arch and indep building and have a
>> meaningfull Build-Depends-Indep.
>
> I think the way to do this is to make the build target depend
> on build-arch and build-indep, so calling build builds everything,
> but allows for a future improvement in efficiency. Assuming, of
> course, that upstream build process also allows for this split up.
We already have that like forever. This is not helping at all since
you can't detect the existance of build-arch/indep in the makefile
correctly and thus dpkg-buildpackage can never call it. So you always
call build and always need all Build-Depends for arch and indep
building. THAT is the core problem.
> manoj
MfG
Goswin
Reply to: