From: Arnold K. <ar...@ar...> - 2007-08-24 18:18:55
|
Hi all, if ffado-development seemed boring to you in the last time, now is a big=20 excitement coming up! /trunk now contains a big merge from pieters redesign of the avc-code (as f= ar=20 as I understand it), he is not quite finished but it works (at least for my= =20 device). And it contains my merge introducing scons as a buildsystem. I did not yet= =20 disable the automagic-system in case something is missing or not working bu= t=20 it works good enough to build a libffado usable by jack (3x256 is running=20 stable here). So while reading on you should do a "svn up" for your local checkout to get= =20 the latest and greatest new changes. :-) Using scons is quite easy, at least if you are used to the "./autogen.sh &&= =20 configure && make && make install": To set options (former configure) you can view the options by "scons -h" wh= ich=20 shows you help texts and default-settings and the current settings. You can= =20 even use "scons -h <OPTION=3Dvalue>" to set options and see the direct effe= ct.=20 Of course scons remembers the options set. Next step (former make) is just "scons" which will build libffado and the=20 tests and apps. "scons install" installs everything needed to use ffado in jack and "scons = =2Dc"=20 cleans the local dir while "scons -c install" does the same and remove the= =20 installed files. The bigger differences for developers are: - If you add files to the project, you don't have to do anything apart fro= m=20 adding them to the corresponding SConscript and build (with "scons").=20 No "./autogen.sh"/<bla> as in auto* is needed. It just works... - I enabled caching for the files which is like using distcache but direct= ly=20 implemented in scons. So if you add some lines of code to one file for=20 testing, compile, test and later on decide to remove the very same lines of= =20 code again (without changing anything else), the next compile will be _way_= =20 shorter than with make, because scons just restores the compiled file from= =20 the run before the lines where added. :-) This can save quite some time.=20 Especially when testing the install-feature. - Configure-checks and build-rules are not written in some cryptic=20 macro-language anymore but in nice, object-oriented python (with the scons= =20 extensions/classes). If you run into any problems or have questions, just ask me (preferable on= =20 this list). Have a nice weekend, Arnold =2D-=20 visit http://www.arnoldarts.de/ =2D-- Hi, I am a .signature virus. Please copy me into your ~/.signature and send= me=20 to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your=20 administrator to do so... |
From: Michael G. <mg...@ti...> - 2007-08-25 11:13:58
|
Hi list, > And it contains my merge introducing scons as a buildsystem. [snip] I have two questions, one of which actually is an old issue I wanted to report for quite some time. a) Both the old automagic build system as well as the new scons based one do install libffado to PREFIX/lib. On 64bit system this should be PREFIX/lib64. b) Which impact does using scons have on creating rpms ? Doesn't rpm rely on the autotools ? Or does rpm use scons when scons is there ? Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ !tagline Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: Arnold K. <ar...@ar...> - 2007-08-25 11:38:20
|
Am Samstag, 25. August 2007 schrieb Michael Gerdau: > > And it contains my merge introducing scons as a buildsystem. > I have two questions, one of which actually is an old issue I wanted > to report for quite some time. > a) Both the old automagic build system as well as the new scons based one > do install libffado to PREFIX/lib. > On 64bit system this should be PREFIX/lib64. One of the issues I have to tackle. Thanks for reminding me. But on most of these systems lib is a symlink to lib64 whereas 32-bit libs = go=20 to lib32 afaik. > b) Which impact does using scons have on creating rpms ? > Doesn't rpm rely on the autotools ? > Or does rpm use scons when scons is there ? ? rpm has almost nothing to do with the build system a source-package uses.= =20 rpm uses yet another kind of configuration-files to make the package=20 configure and build and install (to some sandbox-destination?) and than gra= bs=20 all the resulting files. This process is similar from rpm to deb to gentoos= =20 ebuild-scripts. And if using scons (or even anything but auto*) would make problems with=20 rpm-packages, well, firstly we don't do the packaging so these problems=20 aren't ours :-) And secondly you wouldn't have any package of for example=20 ardour or kde, both which use not auto* for their buildsystem (for example). And even for the packaging scripts using scons simplifies things. Or at lea= st=20 saves the one line where configure is called. So don't worry, distribution wont stop distributing ffado because it uses=20 scons. Have a nice day, Arnold =2D-=20 visit http://www.arnoldarts.de/ =2D-- Hi, I am a .signature virus. Please copy me into your ~/.signature and send= me=20 to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your=20 administrator to do so... |
From: Michael G. <mg...@ti...> - 2007-08-25 12:50:12
|
> > a) Both the old automagic build system as well as the new scons based o= ne > > do install libffado to PREFIX/lib. > > On 64bit system this should be PREFIX/lib64. >=20 > One of the issues I have to tackle. Thanks for reminding me. >=20 > But on most of these systems lib is a symlink to lib64 whereas 32-bit lib= s go=20 > to lib32 afaik. At least on openSUSE 10.2 this is not the case (no lib32 anywhere on the system). Here the problem is "solved" by adding both lib64 and lib to LD_LIBARRY_PATH and putting lib64 before lib. So no showstopper for the time being but obviously something that should be fixed (as you already acknowledged). > > b) Which impact does using scons have on creating rpms ? > > Doesn't rpm rely on the autotools ? > > Or does rpm use scons when scons is there ? >=20 > ? rpm has almost nothing to do with the build system a source-package use= s. AFAICT this is not entirely correct, because... > rpm uses yet another kind of configuration-files to make the package=20 > configure and build and install (to some sandbox-destination?) and than g= rabs=20 > all the resulting files. This process is similar from rpm to deb to gento= os=20 > ebuild-scripts. =2E..rpm's spec files _do_ indeed describe how to invoke the package's build process. However some research here reveals that while rpm seems to default to using the autotools it has the capability to invoke whatever tools are required to build a package. > And if using scons (or even anything but auto*) would make problems with= =20 > rpm-packages, well, firstly we don't do the packaging so these problems=20 > aren't ours :-) Despite the smiley this is a rather unfriendly remark. _IF_ moving to scons would have broken creating rpms (which is does not), than that move would indeed have created the need to maintain the autotool chain outside of the project. Anyway, this is a moot point as are all other remarks I have regarding the rest of your post (which is why I leave them out :) Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ !tagline Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: Arnold K. <ar...@ar...> - 2007-08-25 14:12:51
|
Am Samstag, 25. August 2007 schrieb Michael Gerdau: > > > b) Which impact does using scons have on creating rpms ? > > > Doesn't rpm rely on the autotools ? > > > Or does rpm use scons when scons is there ? > > ? rpm has almost nothing to do with the build system a source-package > > uses. > AFAICT this is not entirely correct, because... > > rpm uses yet another kind of configuration-files to make the package > > configure and build and install (to some sandbox-destination?) and than > > grabs all the resulting files. This process is similar from rpm to deb = to > > gentoos ebuild-scripts. > > ...rpm's spec files _do_ indeed describe how to invoke the package's build > process. However some research here reveals that while rpm seems to defau= lt > to using the autotools it has the capability to invoke whatever tools are > required to build a package. > > > And if using scons (or even anything but auto*) would make problems with > > rpm-packages, well, firstly we don't do the packaging so these problems > > aren't ours :-) > Despite the smiley this is a rather unfriendly remark. It kind of is, yes. > _IF_ moving to scons would have broken creating rpms (which is does not), > than that move would indeed have created the need to maintain the autotool > chain outside of the project. Well, if a rather general tool to create packages relies on only one=20 buildsystem to use, it would be _very_ limited. After all even the kernel=20 doesn't use auto*. And as a lot of programmers and project-bosses will tell you: taking=20 responsibility for binary packages adds a whole lot of more problem, which = is=20 why most free software projects take only the responsibility for the=20 source-packages and provide the binaries only as a convenience for the user= =2E=20 Every bug report is answered by "Did you compile the source yourself? If no= t,=20 please do it and check again." That is mainly just to give the devs more time for programming instead of=20 dealing with packages for the several thousands of different systems. So, yes the remark above is kind of unfriendly. But it is necessary to rese= rve=20 at least some of ppalmers spare time for programming all the new features w= e=20 want to see in ffado instead of him trying to get his head around building= =20 bin-packages for SuSE, Redhat, Mandriva, debian, ubuntu(studio), gentoo,=20 slackware, etc... So, while providing a general buildsystem that works on as many platforms a= s=20 needed (no need for ffado on mac or win:), providing binary packages is not= =20 our concern. And if some distribution uses a tool that only works with auto= *=20 than its their own fault. After all, that is clearly not the case. Even if rpm's spec is optimized fo= r=20 auto*, it probably never relied on it since quite some of the linux-basic=20 packages don't use auto* (some still use make though). > Anyway, this is a moot point as are all other remarks I have regarding the > rest of your post (which is why I leave them out :) Well, now you got me interested! What are the other remarks? Have fun, Arnold =2D-=20 visit http://www.arnoldarts.de/ =2D-- Hi, I am a .signature virus. Please copy me into your ~/.signature and send= me=20 to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your=20 administrator to do so... |
From: Pieter P. <pi...@jo...> - 2007-08-25 14:15:13
|
Michael Gerdau wrote: >>> b) Which impact does using scons have on creating rpms ? >>> Doesn't rpm rely on the autotools ? >>> Or does rpm use scons when scons is there ? >> ? rpm has almost nothing to do with the build system a source-package uses. > > AFAICT this is not entirely correct, because... > >> rpm uses yet another kind of configuration-files to make the package >> configure and build and install (to some sandbox-destination?) and than grabs >> all the resulting files. This process is similar from rpm to deb to gentoos >> ebuild-scripts. > > ...rpm's spec files _do_ indeed describe how to invoke the package's build > process. However some research here reveals that while rpm seems to default > to using the autotools it has the capability to invoke whatever tools are > required to build a package. > >> And if using scons (or even anything but auto*) would make problems with >> rpm-packages, well, firstly we don't do the packaging so these problems >> aren't ours :-) > > Despite the smiley this is a rather unfriendly remark. > > _IF_ moving to scons would have broken creating rpms (which is does not), > than that move would indeed have created the need to maintain the autotool > chain outside of the project. A packaging system that would require a specific build system is broken IMHO. If not, the least you can say is that it's rather short-sighted to rely on the use of autotools. We have plenty of work getting our own stuff right. I don't feel like spending time at workarounds for other project's shortcomings, being it autotools or packaging tools. Greets, Pieter |
From: Michael G. <mg...@ti...> - 2007-08-25 13:27:40
|
> Using scons is quite easy, at least if you are used to the "./autogen.sh = &&=20 > configure && make && make install": It does not work for me, at least not completely. Logged in as normal user I can invoke 'scons' etc. and it seems to do what it should. However 'sudo scons install' fails: mgd@seneca:~/ftp/audio/ieee1394/ffado/libffado> sudo scons install root's password: scons: Reading SConscript files ... KeyError: 'PKG_CONFIG_PATH': File "/home/mgd/ftp/audio/ieee1394/ffado/libffado/SConstruct", line 35: env =3D Environment( tools=3D['default','scanreplace','pyuic'], toolpat= h=3D['admin'], ENV =3D { 'PATH' : os.environ['PATH'], 'PKG_CONFIG_PATH' : o= s.environ['PKG_CONFIG_PATH'] }, options=3Dopts ) File "/usr/lib64/python2.5/UserDict.py", line 22: raise KeyError(key) I have no problem installing ardour this way though. =46or the time being I'll stick to the old autotool chain. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ !tagline Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: Arnold K. <ar...@ar...> - 2007-08-25 14:00:22
|
Am Samstag, 25. August 2007 schrieb Michael Gerdau: > > Using scons is quite easy, at least if you are used to the "./autogen.sh > > && configure && make && make install": > It does not work for me, at least not completely. > Logged in as normal user I can invoke 'scons' etc. and it seems to do what > it should. However 'sudo scons install' fails: > mgd@seneca:~/ftp/audio/ieee1394/ffado/libffado> sudo scons install > root's password: > scons: Reading SConscript files ... > KeyError: 'PKG_CONFIG_PATH': > File "/home/mgd/ftp/audio/ieee1394/ffado/libffado/SConstruct", line 35: > env =3D Environment( tools=3D['default','scanreplace','pyuic'], > toolpath=3D['admin'], ENV =3D { 'PATH' : os.environ['PATH'], 'PKG_CONFIG_= PATH' > : os.environ['PKG_CONFIG_PATH'] }, options=3Dopts ) File > "/usr/lib64/python2.5/UserDict.py", line 22: > raise KeyError(key) > I have no problem installing ardour this way though. Yeah, thats another known (to me) bug. It took me two days to have scons=20 honour the PKG_CONFIG_VARIABLE and import it into the environment for the=20 pkg-config-calls. Now it relies on having the variable set. :-/ Perhaps this evening has some time... So long, Arnold =2D-=20 visit http://www.arnoldarts.de/ =2D-- Hi, I am a .signature virus. Please copy me into your ~/.signature and send= me=20 to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your=20 administrator to do so... |
From: Pieter P. <pi...@jo...> - 2007-08-25 14:10:48
|
Michael Gerdau wrote: >> Using scons is quite easy, at least if you are used to the "./autogen.sh && >> configure && make && make install": > > It does not work for me, at least not completely. > > Logged in as normal user I can invoke 'scons' etc. and it seems to do what > it should. However 'sudo scons install' fails: > > mgd@seneca:~/ftp/audio/ieee1394/ffado/libffado> sudo scons install > root's password: > scons: Reading SConscript files ... > KeyError: 'PKG_CONFIG_PATH': > File "/home/mgd/ftp/audio/ieee1394/ffado/libffado/SConstruct", line 35: > env = Environment( tools=['default','scanreplace','pyuic'], toolpath=['admin'], ENV = { 'PATH' : os.environ['PATH'], 'PKG_CONFIG_PATH' : os.environ['PKG_CONFIG_PATH'] }, options=opts ) > File "/usr/lib64/python2.5/UserDict.py", line 22: > raise KeyError(key) > > I have no problem installing ardour this way though. I fixed this in SVN. > > For the time being I'll stick to the old autotool chain. That will be difficult since the autotool chain is removed as from today. It was broken anyway since I've added new files and I don't want to keep two build systems in sync. We'll have to work out the issues with scons as they come by. That's why it's a development repository. Greets, Pieter |
From: Pieter P. <pi...@jo...> - 2007-08-25 14:10:52
|
Arnold Krille wrote: > Am Samstag, 25. August 2007 schrieb Michael Gerdau: >>> Using scons is quite easy, at least if you are used to the "./autogen.sh >>> && configure && make && make install": >> It does not work for me, at least not completely. >> Logged in as normal user I can invoke 'scons' etc. and it seems to do what >> it should. However 'sudo scons install' fails: >> mgd@seneca:~/ftp/audio/ieee1394/ffado/libffado> sudo scons install >> root's password: >> scons: Reading SConscript files ... >> KeyError: 'PKG_CONFIG_PATH': >> File "/home/mgd/ftp/audio/ieee1394/ffado/libffado/SConstruct", line 35: >> env = Environment( tools=['default','scanreplace','pyuic'], >> toolpath=['admin'], ENV = { 'PATH' : os.environ['PATH'], 'PKG_CONFIG_PATH' >> : os.environ['PKG_CONFIG_PATH'] }, options=opts ) File >> "/usr/lib64/python2.5/UserDict.py", line 22: >> raise KeyError(key) >> I have no problem installing ardour this way though. > > Yeah, thats another known (to me) bug. It took me two days to have scons > honour the PKG_CONFIG_VARIABLE and import it into the environment for the > pkg-config-calls. Now it relies on having the variable set. :-/ > > Perhaps this evening has some time... I think I fixed it, If you have the time to test if the fix still does what you expect, thx. Greets, Pieter |
From: Michael G. <mg...@ti...> - 2007-08-25 15:56:32
|
> I think I fixed it, If you have the time to test if the fix still does=20 > what you expect, thx. That one had been fixed, however I now get this error: mgd@seneca:~/ftp/audio/ieee1394/ffado/libffado> sudo scons install root's password: scons: Reading SConscript files ... Checking for C header file stdio.h... (cached) yes Checking for pkg-config (at least version 0.0.0)... (cached) yes Checking for libraw1394 (1.3.0 or higher)... (cached) yes Checking for libavc1394 (0.5.3 or higher)... (cached) yes Checking for libiec61883 (1.1.0 or higher)... (cached) yes Checking for alsa (1.0.0 or higher)... (cached) yes Checking for libxml++-2.6 (2.13.0 or higher)... (cached) yes Checking for liblo (0.22 or higher)... (cached) yes Checking for dbus-1 (1.0 or higher)... (cached) yes Checking for C header file expat.h... (cached) yes Checking for XML_ExpatVersion() in C library expat... (cached) yes Doing a debug build Package glibmm-2.4 was not found in the pkg-config search path. Perhaps you should add the directory containing `glibmm-2.4.pc' to the PKG_CONFIG_PATH environment variable Package 'glibmm-2.4', required by 'libxml++', not found OSError: 'pkg-config --cflags --libs libxml++-2.6' exited 1: File "/home/mgd/ftp/audio/ieee1394/ffado/libffado/SConstruct", line 148: env.MergeFlags( ["!pkg-config --cflags --libs libxml++-2.6"] ) File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 662: args =3D self.ParseFlags(args) File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 651: do_parse(arg, do_parse) File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 532: for t in arg: me(t, me) File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 537: arg =3D self.backtick(arg[1:]) File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 473: raise OSError("'%s' exited %d" % (command, status)) This happens after I had successfully build it using 'scons' as regular use= r. glibmm-2.4 is installed under /opt/gnome/include and /opt/gnome/lib64. The Package file is under /opt/gnome/lib64/pkgconfig/glibmm-2.4.pc Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ !tagline Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: Arnold K. <ar...@ar...> - 2007-08-25 16:14:53
|
Am Samstag, 25. August 2007 schrieb Michael Gerdau: > mgd@seneca:~/ftp/audio/ieee1394/ffado/libffado> sudo scons install > root's password: > scons: Reading SConscript files ... > Checking for C header file stdio.h... (cached) yes > Checking for pkg-config (at least version 0.0.0)... (cached) yes > Checking for libraw1394 (1.3.0 or higher)... (cached) yes > Checking for libavc1394 (0.5.3 or higher)... (cached) yes > Checking for libiec61883 (1.1.0 or higher)... (cached) yes > Checking for alsa (1.0.0 or higher)... (cached) yes > Checking for libxml++-2.6 (2.13.0 or higher)... (cached) yes > Checking for liblo (0.22 or higher)... (cached) yes > Checking for dbus-1 (1.0 or higher)... (cached) yes > Checking for C header file expat.h... (cached) yes > Checking for XML_ExpatVersion() in C library expat... (cached) yes > Doing a debug build > Package glibmm-2.4 was not found in the pkg-config search path. > Perhaps you should add the directory containing `glibmm-2.4.pc' > to the PKG_CONFIG_PATH environment variable > Package 'glibmm-2.4', required by 'libxml++', not found > OSError: 'pkg-config --cflags --libs libxml++-2.6' exited 1: > File "/home/mgd/ftp/audio/ieee1394/ffado/libffado/SConstruct", line 148: > env.MergeFlags( ["!pkg-config --cflags --libs libxml++-2.6"] ) > File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 66= 2: > args =3D self.ParseFlags(args) > File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 65= 1: > do_parse(arg, do_parse) > File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 53= 2: > for t in arg: me(t, me) > File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 53= 7: > arg =3D self.backtick(arg[1:]) > File "/usr/lib64/python2.5/site-packages/SCons/Environment.py", line 47= 3: > raise OSError("'%s' exited %d" % (command, status)) > This happens after I had successfully build it using 'scons' as regular > user. glibmm-2.4 is installed under /opt/gnome/include and > /opt/gnome/lib64. The Package file is under > /opt/gnome/lib64/pkgconfig/glibmm-2.4.pc Yeah, your glibmm's pkg-config-file is at an unusual location. Your normal= =20 user has PKG_CONFIG_PATH pointing at the right direction. root doesn't have= =20 this variable set and pkg-config therefor only searches the normal dir.=20 Please fix your system... Arnold =2D-=20 visit http://www.arnoldarts.de/ =2D-- Hi, I am a .signature virus. Please copy me into your ~/.signature and send= me=20 to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your=20 administrator to do so... |
From: Michael G. <mg...@ti...> - 2007-08-25 17:10:30
|
> > This happens after I had successfully build it using 'scons' as regular > > user. glibmm-2.4 is installed under /opt/gnome/include and > > /opt/gnome/lib64. The Package file is under > > /opt/gnome/lib64/pkgconfig/glibmm-2.4.pc >=20 > Yeah, your glibmm's pkg-config-file is at an unusual location. Your norma= l=20 > user has PKG_CONFIG_PATH pointing at the right direction. root doesn't ha= ve=20 > this variable set and pkg-config therefor only searches the normal dir.=20 > Please fix your system... This _is_ the normal dir on openSUSE 10.2 I'm don't consider claiming the system being broken helpful. FWIW w/r to the transition from the autotools it is a regression since it used to work there. Talking about that: Why is this package needed when I simply wish to _install_ the SW ? I know this is because at this point scons does not yet know there is nothing to be build. On the other hand the build system IMO should be clever enough not to require things _before_ they are required. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ !tagline Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: Arnold K. <ar...@ar...> - 2007-08-25 18:16:32
|
Am Samstag, 25. August 2007 schrieb Michael Gerdau: > > > This happens after I had successfully build it using 'scons' as regul= ar > > > user. glibmm-2.4 is installed under /opt/gnome/include and > > > /opt/gnome/lib64. The Package file is under > > > /opt/gnome/lib64/pkgconfig/glibmm-2.4.pc > > > > Yeah, your glibmm's pkg-config-file is at an unusual location. Your > > normal user has PKG_CONFIG_PATH pointing at the right direction. root > > doesn't have this variable set and pkg-config therefor only searches the > > normal dir. Please fix your system... > This _is_ the normal dir on openSUSE 10.2 > I'm don't consider claiming the system being broken helpful. Well, clearly the system is broken: pkg-config-files are normally installed= =20 in /usr/lib[64]/pkg-config. For pkg-config to find all the other locations = it=20 depends on the right dirs set in the PKG_CONFIG_PATH-variable. The paths ar= e=20 set correctly in your users environment, but when switching users it is not= =20 set anymore. =3D> It is broken. (Despite the fact that suse is going its=20 strange own way by installing a _lot_ of stuff in /opt which normally belon= gs=20 to /usr...) But maybe its not even suse's fault. I have the feeling that by switching=20 users the environment is not set up properly, what does "su -" followed by= =20 a "echo PKG_CONFIG_PATH" give you? > FWIW w/r=20 > to the transition from the autotools it is a regression since it used > to work there. Talking about that: > Why is this package needed when I simply wish to _install_ the SW ? > I know this is because at this point scons does not yet know there is > nothing to be build. On the other hand the build system IMO should be > clever enough not to require things _before_ they are required. ? Do you like packages compiling for half an hour and then telling you "Oh,= by=20 the way, I also need the <bla> package" and you install it and after anothe= r=20 half an hour it brings the same message but with a different package? That is why package dependencies are checked at the beginning. And the checks are performed everytime scons is invoked to see if something= =20 changed (and because you could have skipped the configure and build step by= =20 just doing "scons install" which would still result in a complete=20 installation, try that with auto* "make: No makefile found"). I know that the handling in our current scons is not optimal (and I will sp= end=20 quite some of my valueable free time to fix it), but just complaining "it=20 worked with auto* and it doesn't now, the new system is bad" is _not_=20 helping. If it worked on windows and doesn't on Linux, please get back to t= he=20 MS-world... Thats my last mail to this thread, promised. Arnold =2D-=20 visit http://www.arnoldarts.de/ =2D-- Hi, I am a .signature virus. Please copy me into your ~/.signature and send= me=20 to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your=20 administrator to do so... |
From: Michael G. <mg...@ti...> - 2007-08-25 18:53:13
|
> But maybe its not even suse's fault. I have the feeling that by switching= =20 > users the environment is not set up properly, what does "su -" followed b= y=20 > a "echo PKG_CONFIG_PATH" give you? Regardless of whether I use 'su -' or sudo: PKG_CONFIG_PATH is set up correctly as is evident by the following: mgd@seneca:~/ariad/23e1> su - Passwort: seneca:~ # echo $PKG_CONFIG_PATH /usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib64/pkgconfig:/u= sr/share/pkgconfig:/opt/kde3/lib64/pkgconfig:/opt/gnome/lib64/pkgconfig:/op= t/gnome/lib64/pkgconfig:/opt/gnome/share/pkgconfig seneca:~ # seneca:~ # logout mgd@seneca:~/ariad/23e1> sudo echo $PKG_CONFIG_PATH root's password: /usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib64/pkgconfig:/u= sr/share/pkgconfig:/opt/kde3/lib64/pkgconfig:/opt/gnome/lib64/pkgconfig:/op= t/gnome/lib64/pkgconfig:/opt/gnome/share/pkgconfig:/usr/lib/pkgconfig:/opt/= kde3/lib/pkgconfig:/opt/gnome/lib/pkgconfig > ? Do you like packages compiling for half an hour and then telling you "O= h, by=20 > the way, I also need the <bla> package" and you install it and after anot= her=20 > half an hour it brings the same message but with a different package? > That is why package dependencies are checked at the beginning. I already wrote, I fully understand why scons does what it does. [carefully reading what I wrote would have told you that] However - and here I repeat myself - I don't buy that scons *HAS*TO* do a full configure before trying an install. The autotools have seperated these tasks into configure and make and I'm confident in principle scons would be able to realize there is no need for a (re-)configure before trying an install. > And the checks are performed everytime scons is invoked to see if somethi= ng=20 > changed (and because you could have skipped the configure and build step = by=20 > just doing "scons install" which would still result in a complete=20 > installation, try that with auto* "make: No makefile found"). I already wrote twice I'm fully aware why scons does what it does. It's just I happen to dislike this approach as it involves lots of repeated checks th= at most of the time are simply superflous because nothing has changed. > I know that the handling in our current scons is not optimal (and I will = spend=20 > quite some of my valueable free time to fix it), but just complaining "it= =20 > worked with auto* and it doesn't now, the new system is bad" is _not_=20 > helping. Please cite correctly. I wrote "w/r to...autotools it is a regression...". I didn't say anything along the lines of good or bad. I don't think it is disputeable that something that used to work and now does not work anymore is anything but a regression. > If it worked on windows and doesn't on Linux, please get back to the =20 > MS-world... I know I never ever mentioned anything about windows or the MS-world. Your outright rude remark is completely out of place and definitely not asked for. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ !tagline Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: Francois.ernoult <fra...@pa...> - 2007-08-26 10:22:51
|
Hi all, There are three reasons why ENABLE_BEBOB is not working: 1) bridgeco-downloader and bebob-sync should not be built by scons. 2) Some '#ifdef ENABLE_BEBOB' are missing in test-debugmodule, test-dll, test-unittests-util and test-unittests-osc. I'll do a patch for that. 3) A merge side effect: 'src/bebob/bebob_functionblock.h' is included = into 'src/libavc/audiosubmit/avc_audiosubmit.cpp' and 'src/libavc/audiosubmit/avc_audiosubmit.h'. In this included file, two functions are declared: serialize(...) and deserialize(...), but they are unavailable when ENANBLE_BEBOB=3Dno. The question is: do we put declarations between '#ifdef ENABLE_BEBOB' = and #endif, or do we compile the code of those two functions even when if ENABLE_BEBOB=3Dno? In short, are serialize(...) and deserialize(...) needed by 'src/libavc/audiosubmit/avc_audiosubmit.cpp'? Regards, Fran=E7ois |
From: Pieter P. <pi...@jo...> - 2007-08-26 12:24:58
|
Francois.ernoult wrote: > Hi all, > > There are three reasons why ENABLE_BEBOB is not working: > > 1) bridgeco-downloader and bebob-sync should not be built by scons. true. > > 2) Some '#ifdef ENABLE_BEBOB' are missing in test-debugmodule, test-dll, > test-unittests-util and test-unittests-osc. I'll do a patch for that. All of these shouldn't have a dependency on BeBoB since they are tests for the generic infrastructure. Probably somewhere there's a stale reference to something bebob related. > > 3) A merge side effect: 'src/bebob/bebob_functionblock.h' is included into > 'src/libavc/audiosubmit/avc_audiosubmit.cpp' and > 'src/libavc/audiosubmit/avc_audiosubmit.h'. > In this included file, two functions are declared: serialize(...) and > deserialize(...), but they are unavailable when ENANBLE_BEBOB=no. > The question is: do we put declarations between '#ifdef ENABLE_BEBOB' and > #endif, or do we compile the code of those two functions even when if > ENABLE_BEBOB=no? > In short, are serialize(...) and deserialize(...) needed by > 'src/libavc/audiosubmit/avc_audiosubmit.cpp'? The code dealing with function blocks is not yet finished. Normally it should be split into a generic 1394TA compliant part and a BeBoB specific part. However currently this is not ready yet since it involves a rather elaborate rewrite. I'm working on this but I can't say when it's going to be finished. Greets, Pieter |
From: Francois.ernoult <fra...@pa...> - 2007-08-26 09:51:42
|
One or two last little things: ENABLE_GENERICAVC is called ENABLE_GENERIC_AVC in SConstruct and SConscript. It's not a problem by itself but -DENABLE_GENERICAVC is the right flag for gcc according the code. When BUILD_TEST=no it is even built at install time. And I still don't know why it tries to install ffado.h at the end of build on my system. Regards, Francois |
From: Daniel W. <wa...@mo...> - 2007-08-29 21:20:46
|
Just a few things I found: - error message reported by gcc do have a wrong path for the files. This screws up emacs and I can't no longer easily jump to the location in the file. I have to open the corresponding file per hand. - 'config.h' is not included by default. I don't know if that is good or bad. just noticed. - 'scons TAGS' would be a nice and useful feature daniel |
From: Arnold K. <ar...@ar...> - 2007-08-30 08:14:36
|
Am Mittwoch, 29. August 2007 schrieb Daniel Wagner: > Just a few things I found: > - error message reported by gcc do have a wrong path for the files. This > screws up emacs and I can't no longer easily jump to the location in the > file. I have to open the corresponding file per hand. They have the path from the root of the buildsystem. Unless you execute sco= ns=20 in a subdirectory by "scons -u". Maybe you can explain it in irc this afternoon/evening... > - 'config.h' is not included by default. I don't know if that is good or > bad. just noticed. It should get generated from config.h.in. At least it does so here (and=20 presumable on ppalmers system too). Or do you mean included as in "#include <config.h>"? Doing that for all fil= es=20 (even the ones that don't need it) means to rebuilt _all_ files if you deci= de=20 to switch prefix or bump the version number. So its only included on=20 demand... Arnold =2D-=20 visit http://www.arnoldarts.de/ =2D-- Hi, I am a .signature virus. Please copy me into your ~/.signature and send= me=20 to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your=20 administrator to do so... |
From: Daniel W. <wa...@mo...> - 2007-08-30 08:33:22
|
Arnold Krille wrote: > Am Mittwoch, 29. August 2007 schrieb Daniel Wagner: >> Just a few things I found: >> - error message reported by gcc do have a wrong path for the files. This >> screws up emacs and I can't no longer easily jump to the location in the >> file. I have to open the corresponding file per hand. > > They have the path from the root of the buildsystem. Unless you execute scons > in a subdirectory by "scons -u". I did following: pwd = /home/wagi/src/libffado/src M-x compile scons -C .. The reported path was 'src/bebob/bebob_avdevice.cpp' and emacs didn't find the file. Emacs suggested '~/src/bebob/bebob_avdevice.cpp' as path which is obviously wrong. I didn't investigate further. IRC, with auto* the reported path was absolute not relative. That might be the root of the problem. > Maybe you can explain it in irc this afternoon/evening... sure, I've joined the ffado channel >> - 'config.h' is not included by default. I don't know if that is good or >> bad. just noticed. > > It should get generated from config.h.in. At least it does so here (and > presumable on ppalmers system too). > > Or do you mean included as in "#include <config.h>"? Doing that for all files > (even the ones that don't need it) means to rebuilt _all_ files if you decide > to switch prefix or bump the version number. So its only included on > demand... sounds reasonable. daniel ps: I have added some *_pkgdata targets for installing the conf files in SConstruct. Don't know if I did t as you would like it, but it seems to work. Though the uncool thing is before you can use the library you have to install it. I mean with 'use' use as developer. Tricks like this don't work anymore: pwd= libffado/src $ export LD_LIBRARY_PATH=/path/to/libffado/src $ ../tests/test-ffado Discover |
From: Arnold K. <ar...@ar...> - 2007-08-30 12:07:25
|
Am Donnerstag, 30. August 2007 schrieben Sie: > ps: I have added some *_pkgdata targets for installing the conf files in > SConstruct. Don't know if I did t as you would like it, but it seems to > work. Though the uncool thing is before you can use the library you have > to install it. I mean with 'use' use as developer. Tricks like this > don't work anymore: > pwd=3D libffado/src > $ export LD_LIBRARY_PATH=3D/path/to/libffado/src > $ ../tests/test-ffado Discover Hm? This works very well here: arnold@riogrande ~/programme/libffado/tests $ ./test-ffado =2E/test-ffado: error while loading shared libraries: libffado.so: cannot o= pen=20 shared object file: No such file or directory arnold@riogrande ~/programme/libffado/tests $ export=20 LD_LIBRARY_PATH=3D/home/arnold/programme/libffado/src/ arnold@riogrande ~/programme/libffado/tests $ ./test-ffado Usage: test-ffado [OPTION...] OPERATION Try `test-ffado --help' or `test-ffado --usage' for more information. no message buffer overruns arnold@riogrande ~/programme/libffado/tests $ I will be back in IRC as soon as I give this laptop to my wife and get her= =20 away from my big pc... Arnold =2D-=20 visit http://www.arnoldarts.de/ =2D-- Hi, I am a .signature virus. Please copy me into your ~/.signature and send= me=20 to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your=20 administrator to do so... |
From: Daniel W. <wa...@mo...> - 2007-08-31 09:38:33
|
>> pwd= libffado/src >> $ export LD_LIBRARY_PATH=/path/to/libffado/src >> $ ../tests/test-ffado Discover > > Hm? This works very well here: > > arnold@riogrande ~/programme/libffado/tests $ ./test-ffado > ./test-ffado: error while loading shared libraries: libffado.so: cannot open > shared object file: No such file or directory > arnold@riogrande ~/programme/libffado/tests $ export > LD_LIBRARY_PATH=/home/arnold/programme/libffado/src/ > arnold@riogrande ~/programme/libffado/tests $ ./test-ffado > Usage: test-ffado [OPTION...] OPERATION > Try `test-ffado --help' or `test-ffado --usage' for more information. > no message buffer overruns > arnold@riogrande ~/programme/libffado/tests $ Yeah sure, this has to work :) But './test-ffado Discover' will search for PREFIX/share/libffado/ffado_driver_bebob.txt. If it doesn't find it, no device discovering will happen. > I will be back in IRC as soon as I give this laptop to my wife and get her > away from my big pc... :) daniel |