For some of us, the "ancient header file system" is still the clearer way of getting dependencies :-D. Feel free to try to tackle the dependency system of other ecosystems (go, rust, java, ...) to really find out how the situation can get much worse. Trying to determine which headers are being included will, once again, force you to implement almost all of the C preprocessor (as was the case with make before). Valid approach would be to have $ build-monitor gcc -o foo foo.c actually execute the command and watch is actually being used by the original gcc executable, similar to what strace does. On Mon, Apr 18, 2022, at 15:59, Φώτης Βαλασιάδης wrote: > Hi again. > > Indeed such a project would better fit inside make's source itself, but > i guess something like this would be silly considering you need to know > all the stuff we are trying to collect in order to write a makefile. > Then again C and C++ 's ancient header file system is also an issue. We > can only dream of a day where modules arrive and we won't have to deal > with header files including order. > > I think we will have to *sed* every single translation unit to find all > the headers. Which is also something that could be easily coded inside > a preprocessor. > > Now I am unfamiliar with monitoring processes. I don't find it hard to > understand how they work or might be implemented but I've never seen > one. Isn't this specific for each operating system though? > > Can you give me a small demo about how it would work? > > I am currently thinking of something like: > $> project gcc -library source.c -oa.out > > Where project is the name of the program and the rest is the command. > But this doesn't seem helpful at all considering how no project > actually uses the compiler manually, and instead uses build systems. > > Which leads to idea number 2: > A background process which periodically looks for gcc/clang/msvc/etc > processes and fetches said statistics. > > I could go on and on about ways which this could be implemented, but > I'd rather hear your version so I can google my way towards > enlightenment 1 and half a day before the proposals deadline. > > Looking forward to it > Φώτης > > Στις Δευ 18 Απρ 2022 στις 4:17 μ.μ., ο/η Alexios Zavras > <zvr+eellak [ at ] zvr [ dot ] gr <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr>> έγραψε: >> Thanks for your interest! >> >> I think a separate program that monitors some build process(es) >> is the most realistic approach. >> In order to implement analysis of build-command files >> (e.g., Makefiles) you would have to implement a substantial >> part of the underlying tool (e.g., make), which might not be >> such an easy task. >> >> An additional step would also be the details for the running >> build command itself: I mean, make only knows up to the point of: >> cc -o foo foo.c >> It does not (and can not) know to record that "this set of files >> were used in the compilation" (e.g., header files). >> >> On Mon, Apr 18, 2022, at 13:26, Φώτης Βαλασιάδης wrote: >> > Hello again! >> > >> > I'd be interested in implementing the Build recorder idea. But I need >> > some clarifications before I submit my proposal. >> > >> > What are the expected results? Are you thinking of a CLI or a tool that >> > reads build configuration files such as CMake files or Make files? >> > >> > To be honest I was surprised to see that CMake doesn't offer an option >> > to provide info about all compilation units, header files and libraries >> > used. >> > >> > Would such a program that analyzes a make file be enough for GSoC? Or >> > are you thinking of a project that supports many build configuration >> > files such as ninja et cetera? >> > >> > TL;DR: Would a project that analyzes make files and fetches which >> > libraries( linked or static ), compilation units , compiler, compiler >> > options and executable it produces suffice? >> > >> > finally do you have any ideas of your own about how this would be >> > implemented? I am thinking of writing a scanner/parser using Flex and >> > Bison but I'd be open to other ideas and I'll even consider reading >> > make's source to see how they handle make files. >> > >> > Thank you for your time >> > Φώτης >> > >> > ---- >> > Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και >> > συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του >> > Google Summer of Code - A discussion list for student developers and >> > mentors of Google Summer of Code projects., >> > https://lists.ellak.gr/gsoc-developers/listinfo.html >> > Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. >> > ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr> >> > <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%252Bunsubscribe [ at ] ellak [ dot ] gr>>>. >> >> -- >> -- zvr - -- -- zvr -
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., https://lists.ellak.gr/gsoc-developers/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.