> I find it a bit irresponsible to leave the suggestion sounding as if > this is a good idea as long as it does not break cross-compilation, > which will (mis)lead the original poster to waste even more time on > this topic (and waste others' time on responding to it). No. no. it's not for the previous replay i am asking for. Back in the days, I was asked by Ævar Arnfjörð Bjarmason. " * It's unclear if you mean that we'd commit the generated files or not. If "not" then our Makefile will need to learn to do two-stage compilation. I.e. we'd ship a copy of the makeheader tool, build that, build the headers, and then do our "real" build." My answer was. "There are different ways we can install the makeheaders tool." As the related question asked, I remembered it. so, I asked as this will solve the cross-compilation problem also, if it is good. > so let me repeat what I already said a few times. > > Whether the headers mechanically generated gets committed or not, > this line of change is unwelcome. Developers should be able to look > at the header files (and interface document, if we ever generate one > out of structured comments in the header files) when using common > functions that they are not (yet) familiar with, and we want to see > our header files manually curated. You repeated the question for me so, really sorry. I know you have already told me that, and it is important also as generally people try to find documentation for function in the header file. It is also not good when sharing libraries and its related header files without documentation. I tried to find the solution. By reading the manual and By viewing the source code, I found it doesn't support it. So, I am going to either modify it or create a new one. And also I have remembered all your points, I will try to implement it. > I'm sorry. > > I thought my earlier voice to not support this proposal was't > necessary to be re-iterated. I only think that if this proposal > somehow got accepted (despite I don't like this proposal), something > needs to be fixed. > > I will be explicit next time. No. no. you don't need to be sorry. I know this proposal is not going to be accepted now. Too many things have to be done here and I am working on it. My question was. 1. Until now, are there any problems which need to be solved. 2. Why it gives errors in CI / win test (8) (pull_request) test. (Important)
