I was just looking at the current agenda and have some input for a couple of the Build System questions:
- >> Should we continue to support generating a makefile?
I’m guessing that the unspoken part of this question is whether the internal builder is sufficient. I can think of a couple of reasons why it may not be:
1. Certainly in the 3.1 timeframe, the internal builder did not implement all of the MBS schema attributes that the makefile generator does. I don’t know how much the internal builder was enhanced in 4.0.
At the least, some significant testing would need to be done using the existing MBS JUnits and other examples to ensure that the internal builder does handle all of the model.
2. Generating makefiles supports the ability start with a managed project and then later decide to convert to a “makefile” project and maintain the makefile yourself. I’m not sure how important this is, but
it would be a loss of functionality.
What are the reasons for removing makefile generation support? Is maintaining the support a large burden?
- Deadlocks, deadlocks, deadlocks
- What is the reason most of these are happening? How can the architecture be changed to help alleviate this?
I looked at this a couple of times some time ago. I believed that the problem had to do with the indexer getting kicked off before the build system information for a project was loaded. The indexer asks for configuration information
and then the build system needs to load the information and somewhere in that process is the deadlock potential. My thought, at the time, was that we needed some mechanism for specifying the set of project open tasks and either an explicit ordering capability,
priority settings, …
If we could get the “phone” attendance working, I could attend the build system discussion on Tuesday or Thursday. I can’t attend on Wednesday.