From: Borut R. <bor...@si...> - 2005-08-04 18:47:40
|
> The problem seems to be caused by ./configure in device/lib/pic16 not > having been run. I used to do this manually before running make in this > directory. Fixed in CVS. > cp: cannot stat `pic16/bin/*.*': Not a directory > > This seems to be due to device/lib/pic16/bin being a FILE rather than a > directory. I've used gplib to see what's in this file. Fixed in device/lib/Makefile by creating device/lib/pic16/bin directory before calling device/lib/pic16 make. > I hope this helps..... It helps a lot! I anticipate additional problems with mingw build, but we will see... Let wait for an other daily snapshot build ;-). Thank you, Borut |
From: Raphael N. <RN...@we...> - 2005-08-05 09:40:22
|
Hi Peter, > One minor niggle remains... the io device library "libio" still isn't > built automatically because it is commented out in the make file. Is > there a reason for this ? If this were corrected the build process > would be the normally expected Actually, there is a reason: building the I/O library cannot be done in a processor independant way (actually one could build it for the largest PIC out there, but that might cause problems with unsupported IO functions on smaller devices like undefined sfr CANCON or the like). Thus we build the library for all PICs mentioned in pics.build which defaults to a copy of pics.all -- thus causing the library to be built ~20 times, once for each supported PIC. To prevent you from accidentally triggering such a long (useless) build the libio is only built when explicitly called for (probably after having realized that one should adopt pics.build first...). On the compile farm (as you could locally) we could build the complete libio by simply adding a call to "make libio" somewhere (I could do it, but I believe Borut (is/has been) working on this, right?). > ./configure > make > su -c "make install" Regards, Raphael Neider |
From: Peter O. <po...@al...> - 2005-08-05 10:43:15
|
On Fri, 2005-08-05 at 11:40 +0200, Raphael Neider wrote: > Hi Peter, > Thus we build the library for all PICs mentioned in pics.build which > defaults to a copy of pics.all -- thus causing the library to be built > ~20 times, once for each supported PIC. > To prevent you from accidentally triggering such a long (useless) build > the libio is only built when explicitly called for (probably after > having realized that one should adopt pics.build first...). I'm building on a 2.6Ghz box with 512Mb RAM. Building just the PIC port with ./configure --disable-mcs51-port --disable-gbz80-port --disable-z80-port --disable-avr-port --disable-ds390-port --disable-ds400-port --disable-hc08-port --disable-xa51-port time make = 2min31s Now with libio included for all the target PICs time make = 3min53s Hardly a "long" build compared for example to gpsim which takes 12min5s. My personal preference would be to make the default build process as simple as possible for the users, even if this does waste about 90 seconds building some unnecessary libraries. The instructions in the manual should cover the changes needed to customise the build if it is an issue for users. Out of interest do the versions built for distribution as binaries have all the target libio's prebuilt ? Peter |
From: Scott D. <sc...@da...> - 2005-08-05 12:49:44
|
Peter, You write about the build times for SDCC and gpsim. In your case, it might make sense to use CCACHE. http://ccache.samba.org/ For gpsim, I write: CXX="ccache g++" ./configure Once the project has been built once, everything is cached on your hard disk. If you change a file dependency, then the dependent code is rebuilt only if CCACHE determines the change affects the resultant object file. I don't think CCACHE may be applicable to nightly SDCC builds though. Scott |
From: Peter O. <po...@al...> - 2005-08-05 13:37:19
|
There are other problems.... Having enabled building of libio , it seems there are problems with dependencies as the libio code it being rebuilt every time , even if no changes have been made, and after running "make install" as root, the copies in the bin directory are owned by root and thus the next time I run make I'm being prompthed like this for every library file... make[6]: Leaving directory `/opt/sdcc-cvs/sdcc/device/lib/pic16/libio' mv -v libio18f442.lib ../bin mv: overwrite `../bin/libio18f442.lib', overriding mode 0644? I'll try and sort out these problems this evening, but I'm not very good with make files etc..... Peter |
From: Peter O. <Pet...@bt...> - 2005-08-04 20:13:03
Attachments:
diff
|
On Thu, 2005-08-04 at 20:47 +0200, Borut Razem wrote: > It helps a lot! I anticipate additional problems with mingw build, but we will see... > Let wait for an other daily snapshot build ;-). > > Thank you, > Borut > Don't be too quick to thank me Borut ! Seems it's broken in a new way ;-) ./configure [SNIP] checking type name for dword... int checking whether byte ordering is bigendian... no configure: creating ./config.status config.status: creating main.mk config.status: error: cannot find input file: main_in.mk This seems to be due to some problem in "configure" at around line 7676 It seems like some "^M" have crept in to the file.... I've attached a diff (it may be the wrong way round though!). Peter |
From: Peter O. <Pet...@bt...> - 2005-08-04 21:10:03
|
On Thu, 2005-08-04 at 21:12 +0100, Peter Onion wrote: It fails later in the build as well ..... make[2]: Entering directory `/opt/sdcc-cvs/sdcc/device/lib' mkdir -p build/pic16 if [ -d pic16 ]; then \ mkdir -p pic16/bin \ make -C pic16; \ cp -f pic16/bin/*.* build/pic16; \ fi mkdir: invalid option -- C Try `mkdir --help' for more information. cp: cannot stat `pic16/bin/*.*': No such file or directory make[2]: *** [port-specific-objects-pic16] Error 1 make[2]: Leaving directory `/opt/sdcc-cvs/sdcc/device/lib' make[1]: *** [model-pic16] Error 2 make[1]: Leaving directory `/opt/sdcc-cvs/sdcc/device/lib' make: *** [sdcc-device] Error 2 Peter |
From: Ken J. <Ken...@ie...> - 2005-08-05 02:20:14
|
Star dot star matches all files in DOS and Windows command shells, but it will only match filenames containing a dot when used in bash under Linux, Cygwin and Mingw32. $ grep -n '[*][.][*]' $(find . -name Make\*) ./device/lib/Makefile:261: cp -f $(PORT)/bin/*.* $(PORTDIR); \ ./device/lib/pic16/Makefile:40: $(RM) -f bin/*.* ./device/lib/Makefile.in:261: cp -f $(PORT)/bin/*.* $(PORTDIR); \ -Ken Jackson |
From: Ken J. <Ken...@ie...> - 2005-08-05 02:27:22
|
I have this exact information on the screen in front of me, but I can't find what Makefile or script was executing. Where is this? I think the problem is that there is no semicolon after 'mkdir -p pic16/bin'. Notice that the error message complains about the C option for 'mkdir', not 'make'. The make command was concatated with the mkdir command above it. I think we only need to add a ';' after the mkdir command. If we can find it. -Ken Jackson Peter Onion writes: > On Thu, 2005-08-04 at 21:12 +0100, Peter Onion wrote: > > It fails later in the build as well ..... > > make[2]: Entering directory `/opt/sdcc-cvs/sdcc/device/lib' > mkdir -p build/pic16 > if [ -d pic16 ]; then \ > mkdir -p pic16/bin \ > make -C pic16; \ > cp -f pic16/bin/*.* build/pic16; \ > fi > mkdir: invalid option -- C > Try `mkdir --help' for more information. > cp: cannot stat `pic16/bin/*.*': No such file or directory > make[2]: *** [port-specific-objects-pic16] Error 1 > make[2]: Leaving directory `/opt/sdcc-cvs/sdcc/device/lib' > make[1]: *** [model-pic16] Error 2 > make[1]: Leaving directory `/opt/sdcc-cvs/sdcc/device/lib' > make: *** [sdcc-device] Error 2 > > > Peter |
From: Peter O. <po...@al...> - 2005-08-05 09:06:03
|
I just tried this again with fresh CVS check out and all seems to have been fixed :-) Great Stuf... One minor niggle remains... the io device library "libio" still isn't built automatically because it is commented out in the make file. Is there a reason for this ? If this were corrected the build process would be the normally expected ./configure make su -c "make install" |
From: Ken J. <Ken...@ie...> - 2005-08-04 21:18:00
|
Excellent! I was trying to narrow it down before I reported it. I just globally deleted all the ^M characters in my local copy of configure and now it works. -Ken Jackson Peter Onion writes: ... > config.status: creating main.mk > config.status: error: cannot find input file: main_in.mk > > > This seems to be due to some problem in "configure" at around line 7676 > It seems like some "^M" have crept in to the file.... > > I've attached a diff (it may be the wrong way round though!). > > Peter ... |