svn@coreboot.org wrote:
Author: stuge Date: 2008-11-25 03:03:16 +0100 (Tue, 25 Nov 2008) New Revision: 3770
Modified: trunk/util/msrtool/TODO trunk/util/msrtool/configure trunk/util/msrtool/msrtool.c trunk/util/msrtool/msrtool.h trunk/util/msrtool/sys.c Log: msrtool: Use libpci to let system and target probes find PCI devices.
And some more notes in TODO.
Signed-off-by: Peter Stuge peter@stuge.se Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Modified: trunk/util/msrtool/TODO
--- trunk/util/msrtool/TODO 2008-11-24 20:23:23 UTC (rev 3769) +++ trunk/util/msrtool/TODO 2008-11-25 02:03:16 UTC (rev 3770) @@ -1,8 +1,9 @@ Systems
FreeBSD #defines: see svn diff -r 3697:3698 util/ +i586: assembly instruction system driver, may have to ignore -c CPU # option
Other ideas
Move MSR definitions and probe instructions into an external text file? -Handle PCI registers as well? +Handle PCI and port IO registers as well?
Modified: trunk/util/msrtool/configure
--- trunk/util/msrtool/configure 2008-11-24 20:23:23 UTC (rev 3769) +++ trunk/util/msrtool/configure 2008-11-25 02:03:16 UTC (rev 3770) @@ -135,6 +135,25 @@ test -n "$DEBUG" && myCFLAGS="-O2 -g" || myCFLAGS="-Os" CFLAGS="${CFLAGS} ${myCFLAGS} -Wall -Werror"
+cat > .config.c << EOF +#include <pci/pci.h> +struct pci_access *pacc; +int main(int argc, char *argv[]) +{ pacc = pci_alloc(); return 0; } +EOF
+pc_CFLAGS="$(pkg-config libpci --cflags 2>/dev/null)" +pc_LDFLAGS="$(pkg-config libpci --libs 2>/dev/null)" +CFLAGS=$(trycompile "libpci (from pciutils)" "${pc_CFLAGS}" "-I/usr/local/include") || {
- rm -f .config.c
- exit 1
Any reason why we don't just drink all the koolaid and use the full autoconf/automake/pkgconfig system in all its glory? This seems to be fairly prone to porting issues - especially the -I/usr/local/include bit.
Jordan
On Tue, Nov 25, 2008 at 8:44 AM, Jordan Crouse jordan@cosmicpenguin.net wrote:
Any reason why we don't just drink all the koolaid and use the full autoconf/automake/pkgconfig system in all its glory? This seems to be fairly prone to porting issues - especially the -I/usr/local/include bit.
glory is not a word I usually associate with that stuff :-)
ron
ron minnich wrote:
On Tue, Nov 25, 2008 at 8:44 AM, Jordan Crouse jordan@cosmicpenguin.net wrote:
Any reason why we don't just drink all the koolaid and use the full autoconf/automake/pkgconfig system in all its glory? This seems to be fairly prone to porting issues - especially the -I/usr/local/include bit.
glory is not a word I usually associate with that stuff :-)
Okay, fair enough. But heres the thing - "that stuff" has already figured out some of the icker bits of trying to find libraries and other such things - and when other people come along to try to adapt this code in their build systems they will appreciate breakage in a common location rather then you introducing new but slightly familiar breakage that they then need to understand.
Jordan
On Tue, Nov 25, 2008 at 9:12 AM, Jordan Crouse jordan@cosmicpenguin.net wrote:
Okay, fair enough. But heres the thing - "that stuff" has already figured out some of the icker bits of trying to find libraries and other such things
- and when other people come along to try to adapt this code in their build
systems they will appreciate breakage in a common location rather then you introducing new but slightly familiar breakage that they then need to understand.
good point. I think if we need it, we need it, it's a (sub)standard, but it is a standard.
ron
Jordan Crouse wrote:
But heres the thing - "that stuff" has already figured out some of the icker bits of trying to find libraries and other such things - and when other people come along to try to adapt this code in their build systems they will appreciate breakage in a common location rather then you introducing new but slightly familiar breakage that they then need to understand.
In practice I don't think we have to consider very many icky bits. flashrom has been using even simpler logic than in that configure script for about three years already and a lot of the time it works well. (r2117)
Things may get more complex as the dependencies stack up, but for the number and type of dependencies we'll have for both msrtool and flashrom I think we can continue to roll our own, and get away without autotools.
//Peter
Jordan Crouse wrote:
+pc_CFLAGS="$(pkg-config libpci --cflags 2>/dev/null)" +pc_LDFLAGS="$(pkg-config libpci --libs 2>/dev/null)" +CFLAGS=$(trycompile "libpci (from pciutils)" "${pc_CFLAGS}" "-I/usr/local/include") || {
- rm -f .config.c
- exit 1
Any reason why we don't just drink all the koolaid and use the full autoconf/automake/pkgconfig system in all its glory?
findprog(), trycompile() and trylink() in the configure script are short, fairly easy to understand and hopefully portable enough.
This seems to be fairly prone to porting issues - especially the -I/usr/local/include bit.
The first parameter to trycompile and trylink is a message, all the rest are CFLAGS that should be tried in order, one at a time, until one is found that will successfully compile/link the file.
So pkg-config output is tried first, if that doesn't work (maybe no pkg-config installed) then -I/usr/local/include is tried. On Gentoo no CFLAGS are needed at all because the library is in /usr and /usr/include is always searched by gcc.
My thinking is that this is flexible enough while staying simpler than autotools. I hope to get a similar configure script into flashrom too, ticket 101.
//Peter
my allergies to autoconfig tools occurred when the openmpi configure script hit 50,000 lines. Now that the openmpi script is 150,000 lines, well, I am even more allergic :-)
ron
Peter Stuge wrote:
Jordan Crouse wrote:
+pc_CFLAGS="$(pkg-config libpci --cflags 2>/dev/null)" +pc_LDFLAGS="$(pkg-config libpci --libs 2>/dev/null)" +CFLAGS=$(trycompile "libpci (from pciutils)" "${pc_CFLAGS}" "-I/usr/local/include") || {
- rm -f .config.c
- exit 1
Any reason why we don't just drink all the koolaid and use the full autoconf/automake/pkgconfig system in all its glory?
findprog(), trycompile() and trylink() in the configure script are short, fairly easy to understand and hopefully portable enough.
Right - but autoconf scripts are portable _without_ hacking. Thats the whole point.
This seems to be fairly prone to porting issues - especially the -I/usr/local/include bit.
The first parameter to trycompile and trylink is a message, all the rest are CFLAGS that should be tried in order, one at a time, until one is found that will successfully compile/link the file.
So pkg-config output is tried first, if that doesn't work (maybe no pkg-config installed) then -I/usr/local/include is tried. On Gentoo no CFLAGS are needed at all because the library is in /usr and /usr/include is always searched by gcc.
My thinking is that this is flexible enough while staying simpler than autotools. I hope to get a similar configure script into flashrom too, ticket 101.
I really wish you would reconsider - this would probably be a three or four line autoconf script (10 with comments). You can't get much simpler then that and you would really be helping out the packaging folks. A home brewed configure script (and one that is named 'configure' to boot) may seem simpler to you, but its just another barrier for others to accept our tools.
Jordan
Jordan Crouse wrote:
findprog(), trycompile() and trylink() in the configure script are short, fairly easy to understand and hopefully portable enough.
Right - but autoconf scripts are portable _without_ hacking. Thats the whole point.
That's sounds a tiny little bit like an urban legend?
I've spend about 5 years of my life (not full time ;-) adapting autoconf stuff from one minor version of autoconf to the next, from one architecture to another, and that was even all for the same linux distribution. My memories tell me the actual architectural problem becomes so small compared to the effort of getting the autoconf stuff running that people start thinking their stuff is actually quite portable otherwise. But of course, YMMV.
Stefan
Stefan Reinauer schrieb:
Jordan Crouse wrote:
findprog(), trycompile() and trylink() in the configure script are short, fairly easy to understand and hopefully portable enough.
Right - but autoconf scripts are portable _without_ hacking. Thats the whole point.
That's sounds a tiny little bit like an urban legend?
No, just like the premise (and promise) of autotools.
Of course, in practice, things look somewhat different: People who rely on that autoscan (or whatever) tool, see that its result works, and are done with that stupid portability work (except that it only works on their machine, and nowhere else). Incompatible undocumented changes in autotools (it wouldn't be a real GNU project without those). People who get confused by the mix of m4, shell (for every shell since 1975), perl and whatever else crosses their way while they desperately try to write a portable test for some feature in their tool. Tests for everything from maximum command line length to existence of stdio.h and the location of the fortran compiler (for a C app!) while not testing for the actual system differences (third party libraries, real system differences like endianess, ...) And lots of other funny issues with autotools.
But in theory, autotools are a great idea!
Regards, Patrick
-
Jordan Crouse -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer