Building and installing processes

Andreas Pakulat apaku at gmx.de
Tue Aug 28 05:35:57 UTC 2012


Hi,

On Tue, Aug 28, 2012 at 2:28 AM, Aleix Pol <aleixpol at kde.org> wrote:
> On Fri, Aug 24, 2012 at 3:54 PM, Andreas Pakulat <apaku at gmx.de> wrote:
>> Hi,
>>
>> On Fri, Aug 24, 2012 at 1:39 PM, Aleix Pol <aleixpol at kde.org> wrote:
>>> On Fri, Aug 24, 2012 at 1:24 PM, Andreas Pakulat <apaku at gmx.de> wrote:
>>>> Hi,
>>>>
>>>> On Fri, Aug 24, 2012 at 12:51 PM, Aleix Pol <aleixpol at kde.org> wrote:
>>>>> On Fri, Aug 24, 2012 at 7:38 AM, Andreas Pakulat <apaku at gmx.de> wrote:
>>>>>> On Fri, Aug 24, 2012 at 12:28 AM, Aleix Pol <aleixpol at kde.org> wrote:
>>>>>>> Hi co-kdevelopers,
>>>>>>> Right now our IProjectBuilders have an IPB::build and an IPB::install.
>>>>>>> It works great, but it has some small integration problems for us
>>>>>>> (cmake).
>>>>>>>
>>>>>>> When you install, you first build then install, but cmake does first
>>>>>>> the build then build+install. So the first part can be omitted. Also
>>>>>>> this generates 2 output views so you don't get to see the warnings.
>>>>>>
>>>>>> Why? I just looked at the code and CMakeBuilder::install only calls
>>>>>> MakeBuilder::install which merely runs "make install".
>>>>>> CMakeBuilder::install may also run cmake first and that would be a
>>>>>> possibly separate outputview, but thats a different thing already
>>>>>> IMHO.
>>>>>>
>>>>>> So are you saying that the "install" action first runs
>>>>>> IProjectBuilder::build and then IProjectBuilder::install? Maybe thats
>>>>>> a bit too much dependency-management on our side and we should simply
>>>>>> drop it? After all a build-system is called a build-system because it
>>>>>> should take care of first building what needs to be built before
>>>>>> installing it anyway. I'd consider any buildsystem not doing this to
>>>>>> be broken.
>>>>>
>>>>> What I mean is that "install" itself is building already, so the build
>>>>> step is redundant, for cmake. We could call install/fast otherwise
>>>>> (with the make builder).
>>>>
>>>> Yes, I got that much. I'm merely wondering which code is running
>>>> IProjectBuilder::build and then IProjectBuilder::install. I couldn't
>>>> find any actually and I'd say if there is such code it should be
>>>> reduced to calling just ::install.
>>>>
>>>> A buildsystem (ninja, make, whatever-your-custom-one-is) should always
>>>> allow to setup dependencies between the install rules and the stuff
>>>> thats needed to build before it can be installed. A buildsystem that
>>>> requires a human user to always run make before make install is just
>>>> broken and not supported by kdevelop. IMHO thats a reasonable
>>>> restriction to have.
>>>>
>>>> Hence KDevelop can simply always issue just IProjectBuilder::install()
>>>> and the CMake Builder implementation should then just issue "make
>>>> install".
>>>>
>>>> Andreas
>>>>
>>>> --
>>>> KDevelop-devel mailing list
>>>> KDevelop-devel at kdevelop.org
>>>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>>>
>>> Yes, it's in executeplugin.cpp:144.
>>> Ok so we can just drop the ::Build line there and be happy? Works for me :)
>>
>> Ah, its about executing. Well, looking at the history indicates that
>> Andras did this intentionally, so I'd suggest to first check with him
>> why he separated build and install.
>>
>> Andreas
>>
>> --
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
> It looks like the problem is that if you turn on the _install using
> root_ feature, then you want to build with the user and install with
> root.
>
> I guess we should control this use case in the builder, then?

Yes, the builder should generate a composite job which runs a build
and a 'install as root' job one after the other. The execute-plugin
has no access to the 'install as root' info anyway and shouldn't need
it, the builder should take care of doing the right thing. After all
the same problem exists when the user just hits the "Install" action.

Andreas




More information about the KDevelop-devel mailing list