Alright! This is absolutely do-able, once again using bison / flex for the CLI or something similar. I expected that I'd need to use C or C++ for said project but the way you describe it makes it seem that I could code it in anything, even in a scripting language such as bash. Whatever is best and simplest , I'll do (ποιον κοροϊδεύω; C++). Thanks for answering my questions, I will now rush to put together a structured proposal so I can submit it by tomorrow GMT+03 12:00 military time and give whoever will be reviewing it time. One final question, in the proposal template it says i should state IRC nickname on #sugar The point is I don't own an account, should I absolutely get one? And if yes, where do I register? Thanks for your help once again! Φώτης Στις Δευ 18 Απρ 2022 στις 9:17 μ.μ., ο/η Alexios Zavras <zvr+eellak [ at ] zvr [ dot ] gr> έγραψε: > 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>.