All communication details except an email are optional -- having an IRC account is definitely not required. On Mon, Apr 18, 2022, at 21:16, Φώτης Βαλασιάδης wrote: > 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 <mailto:zvr%2Beellak [ 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> <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr <mailto:zvr%252Beellak [ 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>> >> >> > <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%252Bunsubscribe [ at ] ellak [ dot ] gr> <mailto:gsoc-developers%252Bunsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%25252Bunsubscribe [ at ] ellak [ dot ] gr>>>>. >> >> >> >> -- >> >> -- zvr - >> >> -- >> -- 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>.