Re: [Xen-devel] [Minios-devel] Excited for Xen Project in Outreachy

[Lars Kurth]

Hi Kanika,

> On 24 Feb 2018, at 20:40, KANIKA SAINI  wrote:
> 
> Thank you, Lars. 
> The links you have provided have managed to make things clearer to me now.
> 
> I understand how a flag in the makefile can be changed by passing a parameter 
> to the make command in the command line and how 
> "origin" checks where the variable comes from.
> I did realize creating the dependency of the Makefile itself would indeed not 
> be a good idea at the finer level of granularity. 
> I went through the documentation at 
> http://unikraft.neclab.eu/developers-app.html 
>  and can now understand the 
> structure of makefiles of libraries better. 
> 
> I spent some time studying the problem and came across this solution at 
> https://www.cmcrossroads.com/article/rebuilding-when-cppflags-changes 
>  which 
> uses the concept of signatures. 
> I also understood how rules are dynamically being set by the Makefiles in 
> support/build/ directory. 
> 
> To be able to draft a solution there's one more thing lacking my 
> understanding, which is the order of the execution of the makefiles. 
> What calls the dynamic makefiles and when is the main makefile called and how 
> do the dynamic makefiles pass those parameters to the main one?

I am not sure I understand your question.

Generally, you can debug makefiles which can help you understand what is going 
on: e.g. see http://www.oreilly.com/openbook/make3/book/ch12.pdf 


But in a nutshell: you call make ... in your directory and the Makefile is 
invoked
* Other rules, e.g. in support / build are included via include statements
* All the other *.uk makefiles are also included 
=> The makefile in unikraft / unikraft.git drives everything related to 
building and configuration (including menuconfig)

In some cases you have nested makefile execution, where another makefile is 
invoked via "@make" as in the Hello World app

Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [Minios-devel] Excited for Xen Project in Outreachy

[KANIKA SAINI]

Thank you, Lars.
The links you have provided have managed to make things clearer to me now.

I understand how a flag in the makefile can be changed by passing a
parameter to the make command in the command line and how
"origin" checks where the variable comes from.
I did realize creating the dependency of the Makefile itself would indeed
not be a good idea at the finer level of granularity.
I went through the documentation at
http://unikraft.neclab.eu/developers-app.html and can now understand the
structure of makefiles of libraries better.

I spent some time studying the problem and came across this solution at
https://www.cmcrossroads.com/article/rebuilding-when-cppflags-changes which
uses the concept of signatures.
I also understood how rules are dynamically being set by the Makefiles in
support/build/ directory.

To be able to draft a solution there's one more thing lacking my
understanding, which is the order of the execution of the makefiles.
What calls the dynamic makefiles and when is the main makefile called and
how do the dynamic makefiles pass those parameters to the main one?

According to what I understood, the flags for the addition of new libraries
or new configurations through the menu config are already being taken care
of by the dynamic checking if that's right. We only have to handle the
additional flags passed through the command line.

I appreciate your time and guidance.

Thank you.




‌

On Fri, Feb 23, 2018 at 2:31 PM, Lars Kurth 
wrote:

> Hi Kanika,
>
> On 22 Feb 2018, at 20:34, KANIKA SAINI  wrote:
>
> *Issue suggested by Simon*
> In Unikraft - whenever compiler flags are changed due to an addition of a
> library or something else according to the build rules, the make command
> doesn't force recompilation of those files affected by the flag change
> unless the files are altered too. The only way out is to "make clean" and
> "make" again all the files which can be redundantly time-consuming.
>
>
> *Solution*One way is to create flag files for objects and add those as
> their dependency in the Makefile.
>
>
>
> Apart from this, I'm wondering if rules are passed on to the Makefile and
> changes are depicted in the Makefile itself, can we add Makefile as the
> dependency of objects to solve this issue?
>
>
> I think the answer is in the documentation, which explains the UI (if you
> to call it that way) for the build system (see http://unikraft.neclab.
> eu/developers-app.html)
>
> You can also usually figure out which parameters are passed to make via
> the command line by searching for the origin function, in particular for
> "command line" return values (https://www.gnu.org/software/
> make/manual/html_node/Origin-Function.html). This will give you a sense
> of the values that can be passed to the build system from outside of a
> makefile.
>
> Now, you do need to make sure that you don't change the UI interface, as
> this would break everyone who uses Unikraft.
>
> Assuming that all the flags we care about are already encoded in a
> Makefile (and don't come through the command line or through any other
> means), then adding a dependency may be sufficient. There is the question
> how granular you want this to be:
> a) Is it OK for everything to be rebuilt when say you change a -Dfoo
> b) Do you want this to be more fine grained
>
> Have a google for something like "rebuilding when makefile flags change"
> and you will find a few example patterns with different trade-offs to solve
> this problem in general
>
> The second challenge is that most substantial build rules get created
> dynamically via* [unikraft/unikraft.git]
>  / 
> support
> 
>  / build
> 
>  /
> * *
> Thus, adding a dependency on a makefile may not be as simple as it sounds
>
> Lars
>



-- 
Yours sincerely,
Kanika Saini
CSE, IIITD Class of 2020
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel