[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: Review Request: Allow to pass multiple targets and build variables to the make builder
From:       "Andreas Pakulat" <apaku () gmx ! de>
Date:       2012-04-15 8:54:37
Message-ID: 20120415085437.22142.21095 () vidsolbach ! de
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


> On April 13, 2012, 9:27 p.m., Milian Wolff wrote:
> > projectbuilders/makebuilder/imakebuilder.h, line 42
> > <http://git.reviewboard.kde.org/r/104537/diff/2/?file=56290#file56290line42>
> > 
> > please don't inline this (it's virtual anyways), put it into the .cpp file
> 
> Alexandre Courbot wrote:
> There is no cpp file for IMakeBuilder yet, but ok.
> 
> Andreas Pakulat wrote:
> If you're adding non-pure-virtual functions to IMakeBuilder you're doing the wrong \
> thing already. The interface should not have any such functions, its just an API \
> definition. 
> Milian Wolff wrote:
> true, apaku has a point. leave the default-implementation to the implemenation, not \
> to the interface. 
> Alexandre Courbot wrote:
> How about IProjectBuilder, which also has implemented methods for e.g. configure()? \
> I am fine with slipping these into the implementation, but this means code \
> duplication if another implementation gets in. We are using C++, not Java - is \
> there any *practical* reason to take interfaces so literally? 
> Alexandre Courbot wrote:
> Giving it a second thought, keeping executeMakeTarget() purely virtual would not \
> break the ABI, which is good. I will only extend IMakeBuilder with a multi-target + \
> variables variant of it and it should fulfill the purpose while keeping things \
> purely virtual.

IProjectbuilder's non-pure virtual methods should be made pure-virtual too. Thats \
probably just an oversight and duplicating a "return 0" is fine IMHO, since most \
buildsystem will actually not even do that. 


> On April 13, 2012, 9:27 p.m., Milian Wolff wrote:
> > projectbuilders/makebuilder/imakebuilder.h, line 26
> > <http://git.reviewboard.kde.org/r/104537/diff/2/?file=56290#file56290line26>
> > 
> > hm a QMap will implicitly sort the variables, that might not be desired. i.e. if \
> > you want to have 
> > make FOO=bar ASDF=asdf
> > 
> > you will actually get
> > 
> > make ASDF=asdf FOO=bar
> > 
> > instead it might be better to just go for a QStringList of arguments, which would \
> > also allow stuff like 
> > make FOO BAR
> > 
> > (i.e. not A=B but just A B)
> 
> Alexandre Courbot wrote:
> These are variables, not no targets - their order do not matter, as they are just \
> going to prevent same-name variables from being defined in the Makefile. 
> http://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_9.html#SEC90
> 
> And as the same document says, the use of '=' is what differentiates a variable \
> from a target in the command line. In your last example, FOO and BAR are targets, \
> not variables. The order of targets does matter, but they already use a \
> QStringList. 
> So apart from a cosmetic point of view (QMap<QString, QString> might not be so \
> elegant to have around, maybe a typedef would be better?), it seems to me that QMap \
> is totally adequate here. 
> Andreas Pakulat wrote:
> I agree with Alexandre, a quick test shows that variables on the commandline cannot \
> reference each other so the order is completely irrelevant. In such a case a QMap \
> is ok I believe and makes it easier to handle addition/removal. It should also be \
> fast enough since there are not many variables set usually. 
> Milian Wolff wrote:
> well, then this is OK with me
> 
> Alexandre Courbot wrote:
> I will just add a typedef to make things easier to read.
> 
> Alexandre Courbot wrote:
> As pointed out by Wolfgang on the list:
> 
> They do if you happen to set the same variable twice:
> make X=abc X=def
> will produce different results than
> make X=def X=abc
> 
> So I will change that to a list of string pairs.

But I don't think we have to care about this in a GUI application. This might be an \
interesting use-case when auto-generating make calls, but a user can easily choose \
one or the other value. So I'd say a QMap is still the correct thing to do - unless \
make has a way to access both values which I doubt.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104537/#review12409
-----------------------------------------------------------


On April 15, 2012, 8:19 a.m., Alexandre Courbot wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104537/
> -----------------------------------------------------------
> 
> (Updated April 15, 2012, 8:19 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
> This change augments the IMakeBuilder interface and MakeBuilder class to let them \
> support the following: 
> 1) Let make be run with multiple targets to build in one run
> 2) Pass build variables as a QMap of (variable, value) pairs that are also passed \
> to make's command line. 
> E.g. this change now makes it possible for the make builder to perform make \
> invokations that look like the following (example taken from an actual Linux kernel \
> build): 
> $ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-elf- vmlinux modules
> 
> API compatibility is not broken, but ABI is as the former virtual method of \
> IMakeBuilder is now an inline function. 
> 
> Diffs
> -----
> 
> projectbuilders/makebuilder/imakebuilder.h 56735425d78551883f109e942145eba2aa982687 \
>  projectbuilders/makebuilder/makebuilder.h 34881c6eaee775b6b8b53959dfcf825732e806da \
>  projectbuilders/makebuilder/makebuilder.cpp \
> 6c6905db30f469958f4a0048826febea29bad15a  projectbuilders/makebuilder/makejob.h \
> 19032fdf371da793d52b3457e5aa78a6b8458150  projectbuilders/makebuilder/makejob.cpp \
> ad5636dbfdadf3ae18ad1cc5b8dff078dd34cd42  
> Diff: http://git.reviewboard.kde.org/r/104537/diff/
> 
> 
> Testing
> -------
> 
> Ensured API remained compatible and prior API behaved identically, tested build \
> variables with the kdev-kernel plugin that uses them. 
> 
> Thanks,
> 
> Alexandre Courbot
> 
> 


[Attachment #5 (text/html)]

<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;">  <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="http://git.reviewboard.kde.org/r/104537/">http://git.reviewboard.kde.org/r/104537/</a>
  </td>
    </tr>
   </table>
   <br />








<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <p style="margin-top: 0;">On April 13th, 2012, 9:27 p.m., <b>Milian \
Wolff</b> wrote:</p>  <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;">  



<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; \
border-collapse: collapse; margin: 2px padding: 2px;">  <thead>
  <tr>
   <th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; \
font-size: 9pt; padding: 4px 8px; text-align: left;">  <a \
href="http://git.reviewboard.kde.org/r/104537/diff/2/?file=56290#file56290line26" \
style="color: black; font-weight: bold; text-decoration: \
underline;">projectbuilders/makebuilder/imakebuilder.h</a>  <span style="font-weight: \
normal;">

     (Diff revision 2)

    </span>
   </th>
  </tr>
 </thead>

 <tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
  <tr>

   <td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; \
"></pre></td>

  </tr>
 </tbody>




 
 



 <tbody>

  <tr>
    <th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2"></font></th>  <td bgcolor="#c5ffc4" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>  <th \
bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid \
#C0C0C0;" align="right"><font size="2">26</font></th>  <td bgcolor="#c5ffc4" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span \
class="cp">#include &lt;QMap&gt;</span></pre></td>  </tr>

 </tbody>

</table>

  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">hm a QMap will \
implicitly sort the variables, that might not be desired. i.e. if you want to have

make FOO=bar ASDF=asdf

you will actually get

make ASDF=asdf FOO=bar

instead it might be better to just go for a QStringList of arguments, which would \
also allow stuff like

make FOO BAR

(i.e. not A=B but just A B)</pre>
 </blockquote>



 <p>On April 14th, 2012, 3:17 a.m., <b>Alexandre Courbot</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">These are variables, not \
no targets - their order do not matter, as they are just going to prevent same-name \
variables from being defined in the Makefile.

http://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_9.html#SEC90

And as the same document says, the use of &#39;=&#39; is what differentiates a \
variable from a target in the command line. In your last example, FOO and BAR are \
targets, not variables. The order of targets does matter, but they already use a \
QStringList.

So apart from a cosmetic point of view (QMap&lt;QString, QString&gt; might not be so \
elegant to have around, maybe a typedef would be better?), it seems to me that QMap \
is totally adequate here.</pre>  </blockquote>





 <p>On April 14th, 2012, 7:54 a.m., <b>Andreas Pakulat</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I agree with Alexandre, \
a quick test shows that variables on the commandline cannot reference each other so \
the order is completely irrelevant. In such a case a QMap is ok I believe and makes \
it easier to handle addition/removal. It should also be fast enough since there are \
not many variables set usually.</pre>  </blockquote>





 <p>On April 14th, 2012, 9:21 p.m., <b>Milian Wolff</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">well, then this is OK \
with me</pre>  </blockquote>





 <p>On April 15th, 2012, 6:44 a.m., <b>Alexandre Courbot</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I will just add a \
typedef to make things easier to read.</pre>  </blockquote>





 <p>On April 15th, 2012, 7:46 a.m., <b>Alexandre Courbot</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">As pointed out by \
Wolfgang on the list:

They do if you happen to set the same variable twice:
 make X=abc X=def
will produce different results than
 make X=def X=abc

So I will change that to a list of string pairs.</pre>
 </blockquote>







</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">But I \
don&#39;t think we have to care about this in a GUI application. This might be an \
interesting use-case when auto-generating make calls, but a user can easily choose \
one or the other value. So I&#39;d say a QMap is still the correct thing to do - \
unless make has a way to access both values which I doubt.</pre> <br />

<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <p style="margin-top: 0;">On April 13th, 2012, 9:27 p.m., <b>Milian \
Wolff</b> wrote:</p>  <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;">  



<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; \
border-collapse: collapse; margin: 2px padding: 2px;">  <thead>
  <tr>
   <th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; \
font-size: 9pt; padding: 4px 8px; text-align: left;">  <a \
href="http://git.reviewboard.kde.org/r/104537/diff/2/?file=56290#file56290line42" \
style="color: black; font-weight: bold; text-decoration: \
underline;">projectbuilders/makebuilder/imakebuilder.h</a>  <span style="font-weight: \
normal;">

     (Diff revision 2)

    </span>
   </th>
  </tr>
 </thead>

 <tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
  <tr>

   <td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; \
"></pre></td>

  </tr>
 </tbody>




 
 



 <tbody>

  <tr>
    <th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2"></font></th>  <td bgcolor="#c5ffc4" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>  <th \
bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid \
#C0C0C0;" align="right"><font size="2">42</font></th>  <td bgcolor="#c5ffc4" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">    <span \
class="p">{</span></pre></td>  </tr>

 </tbody>

</table>

  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">please don&#39;t inline \
this (it&#39;s virtual anyways), put it into the .cpp file</pre>  </blockquote>



 <p>On April 14th, 2012, 3:17 a.m., <b>Alexandre Courbot</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">There is no cpp file for \
IMakeBuilder yet, but ok.</pre>  </blockquote>





 <p>On April 14th, 2012, 7:54 a.m., <b>Andreas Pakulat</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">If you&#39;re adding \
non-pure-virtual functions to IMakeBuilder you&#39;re doing the wrong thing already. \
The interface should not have any such functions, its just an API definition.</pre>  \
</blockquote>





 <p>On April 14th, 2012, 9:23 p.m., <b>Milian Wolff</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">true, apaku has a point. \
leave the default-implementation to the implemenation, not to the interface.</pre>  \
</blockquote>





 <p>On April 15th, 2012, 6:44 a.m., <b>Alexandre Courbot</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">How about \
IProjectBuilder, which also has implemented methods for e.g. configure()? I am fine \
with slipping these into the implementation, but this means code duplication if \
another implementation gets in. We are using C++, not Java - is there any *practical* \
reason to take interfaces so literally?</pre>  </blockquote>





 <p>On April 15th, 2012, 8:01 a.m., <b>Alexandre Courbot</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Giving it a second \
thought, keeping executeMakeTarget() purely virtual would not break the ABI, which is \
good. I will only extend IMakeBuilder with a multi-target + variables variant of it \
and it should fulfill the purpose while keeping things purely virtual.</pre>  \
</blockquote>







</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">IProjectbuilder&#39;s non-pure virtual methods should be made \
pure-virtual too. Thats probably just an oversight and duplicating a &quot;return \
0&quot; is fine IMHO, since most buildsystem will actually not even do that. </pre> \
<br />




<p>- Andreas</p>


<br />
<p>On April 15th, 2012, 8:19 a.m., Alexandre Courbot wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;">  <tr>
  <td>

<div>Review request for KDevelop.</div>
<div>By Alexandre Courbot.</div>


<p style="color: grey;"><i>Updated April 15, 2012, 8:19 a.m.</i></p>






<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0">  <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">This change augments the IMakeBuilder interface and MakeBuilder class to \
let them support the following:

1) Let make be run with multiple targets to build in one run
2) Pass build variables as a QMap of (variable, value) pairs that are also passed to \
make&#39;s command line.

E.g. this change now makes it possible for the make builder to perform make \
invokations that look like the following (example taken from an actual Linux kernel \
build):

$ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-elf- vmlinux modules

API compatibility is not broken, but ABI is as the former virtual method of \
IMakeBuilder is now an inline function.</pre>  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0">  <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Ensured API remained compatible and prior API behaved identically, \
tested build variables with the kdev-kernel plugin that uses them.</pre>  </td>
 </tr>
</table>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>projectbuilders/makebuilder/imakebuilder.h <span style="color: \
grey">(56735425d78551883f109e942145eba2aa982687)</span></li>

 <li>projectbuilders/makebuilder/makebuilder.h <span style="color: \
grey">(34881c6eaee775b6b8b53959dfcf825732e806da)</span></li>

 <li>projectbuilders/makebuilder/makebuilder.cpp <span style="color: \
grey">(6c6905db30f469958f4a0048826febea29bad15a)</span></li>

 <li>projectbuilders/makebuilder/makejob.h <span style="color: \
grey">(19032fdf371da793d52b3457e5aa78a6b8458150)</span></li>

 <li>projectbuilders/makebuilder/makejob.cpp <span style="color: \
grey">(ad5636dbfdadf3ae18ad1cc5b8dff078dd34cd42)</span></li>

</ul>

<p><a href="http://git.reviewboard.kde.org/r/104537/diff/" style="margin-left: \
3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>



-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic