[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 <lars.kurth.xen@xxxxxxxxx> wrote:
Hi Kanika,

On 22 Feb 2018, at 20:34, KANIKA SAINI <kanika16047@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.