3 ms·

There's a big note about how it only works on Linux and how FreeBSD and Mac OS support has atrophied. I take this to be related to the syscall sniffing stuff w

There's a big note about how it only works on Linux and how FreeBSD and Mac OS support has atrophied. I take this to be related to the syscall sniffing stuff which is at its heart. Maybe I'm just conservative, but that kind of design is not the sort of thing I would ever want to rely on.

jamesaguilar 14y ago
Maybe. There's not really another way I can think of to get a perfect picture of what the compiler is going to ask for.
- rachelbythebay 14y ago
  I suspect your code may already have all of this right in the source. #include <stdio.h> #include <mysql/mysql.h> #include "base/logging.h" #include "http/cookie.h" // ... and so on. Right there, you can translate that into a system header you can ignore, a system header for which you should add cflags and ldflags where appropriate (compiling vs. linking), and a couple of local libraries which need to be further investigated. http/cookie.h and base/logging.h are then analyzed, along with http/cookie.cc and base/logging.cc, assuming they exist. Any #includes there are chased down in the same manner. This continues until everything has been resolved. If you keep track of all of these things, then you will have a list of every object file which needs to be rolled up into the final binary. You also pick up all of the flags required to compile and/or link with those things by extension. Obviously you have to handle the whole "rebuild if something changes" thing, but that's not particularly difficult, either. I wrote my own tool to do exactly this. I'm using it for my own (C++) projects, and it's been quite pleasant. It won't work for everyone, though. I wrote about it here: http://rachelbythebay.com/w/2012/03/28/build/ http://rachelbythebay.com/w/2012/03/28/build/
  - jamesaguilar 14y ago
    As long as every c file has an h file with the exact same name, and every lib has precisely one so file, with the same name, I tend to agree. Although I know many projects for which this is not the case.

jamesaguilar 14y ago

Maybe. There's not really another way I can think of to get a perfect picture of what the compiler is going to ask for.

rachelbythebay 14y ago
I suspect your code may already have all of this right in the source. #include <stdio.h> #include <mysql/mysql.h> #include "base/logging.h" #include "http/cookie.h" // ... and so on. Right there, you can translate that into a system header you can ignore, a system header for which you should add cflags and ldflags where appropriate (compiling vs. linking), and a couple of local libraries which need to be further investigated. http/cookie.h and base/logging.h are then analyzed, along with http/cookie.cc and base/logging.cc, assuming they exist. Any #includes there are chased down in the same manner. This continues until everything has been resolved. If you keep track of all of these things, then you will have a list of every object file which needs to be rolled up into the final binary. You also pick up all of the flags required to compile and/or link with those things by extension. Obviously you have to handle the whole "rebuild if something changes" thing, but that's not particularly difficult, either. I wrote my own tool to do exactly this. I'm using it for my own (C++) projects, and it's been quite pleasant. It won't work for everyone, though. I wrote about it here: http://rachelbythebay.com/w/2012/03/28/build/ http://rachelbythebay.com/w/2012/03/28/build/
- jamesaguilar 14y ago
  As long as every c file has an h file with the exact same name, and every lib has precisely one so file, with the same name, I tend to agree. Although I know many projects for which this is not the case.