From: Maarten B. <sou...@ds...> - 2014-03-27 21:06:44
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head> <title></title> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <meta http-equiv="Content-Style-Type" content="text/css"/> </head> <body> <div align="left"><font face="Courier New" size="2"><span style=" font-size:10pt">Hello SDCC friends,</span></font></div> <div align="left"><font face="Courier New" size="2"><span style=" font-size:10pt"><br /> </span></font></div> <div align="left"><font face="Courier New" size="2"><span style=" font-size:10pt">After again almost a full week delay due to problems in our distributed compile farm, I finally made the second Release Candidate (RC2) for SDCC 3.4.0. It has been put online in our SourceForge File section. </span></font><a href="https://sourceforge.net/projects/sdcc/files/"><font face="Courier New" color="#008000" size="2"><span style=" font-size:10pt"> <u>https://sourceforge.net/projects/sdcc/files/</u></span></font></a></div> <div align="left"><font face="Courier New" size="2"><span style=" font-size:10pt"><br /> </span></font></div> <div align="left"><font face="Courier New" size="2"><span style=" font-size:10pt">If you have the time, please verify it and report back with the positive or negative results. If all goes well we can still make the release this month.</span></font></div> <div align="left"><font face="Courier New" size="2"><span style=" font-size:10pt"><br /> </span></font></div> <div align="left"><font face="Courier New" size="2"><span style=" font-size:10pt">May the Source be with you,</span></font></div> <div align="left"><font face="Courier New" size="2"><span style=" font-size:10pt">Maarten Brock</span></font></div> <div align="left"> </div> </body> </html> |
From: Philipp K. K. <pk...@sp...> - 2014-03-28 07:42:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27.03.2014 22:06, Maarten Brock wrote: > Hello SDCC friends, > > After again almost a full week delay due to problems in our > distributed compile farm, I finally made the second Release > Candidate (RC2) for SDCC 3.4.0. It has been put online in our > SourceForge File section. > _https://sourceforge.net/projects/sdcc/files/_ > > If you have the time, please verify it and report back with the > positive or negative results. If all goes well we can still make > the release this month. > > May the Source be with you, Maarten Brock > Should there be an announcement on the website? Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlM1J+MACgkQbtUV+xsoLpqH6wCgxmfjd3S4HpAVNWVwtgFZEU8o TxUAoKxDHfgiiUZI6yO6eRxac6FevQBU =yk/x -----END PGP SIGNATURE----- |
From: Philipp K. K. <pk...@sp...> - 2014-03-30 08:44:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: > Hi again Is there any simple way to exclude the non-free directory > from being built? It is quite simple in version 3.3 but I cannot > build version 3.4. In order to get the package into Debian I need > to remove the whole non-free directory and this causes compilation > errors. Maarten, should we try to sort this out before the release, even if it delays the release? Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlM32U0ACgkQbtUV+xsoLpqBbACgki6O8UkP8kmiNWrsffJbiPwj kdIAoJGKcxz3FF8GQvW5lA6dIjISNUAI =AkM3 -----END PGP SIGNATURE----- |
From: Maarten B. <sou...@ds...> - 2014-03-30 09:22:46
|
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: >> Hi again Is there any simple way to exclude the non-free directory >> from being built? It is quite simple in version 3.3 but I cannot >> build version 3.4. In order to get the package into Debian I need >> to remove the whole non-free directory and this causes compilation >> errors. > > Maarten, > > should we try to sort this out before the release, even if it delays > the release? > > Philipp We could. But it will mean at least another week of delay. I'm guessing about half a week to fix both problems reported by Gudjon and create RC3 and then another half week for testing RC3 before the release. If nobody objects to the delay before 15:00 GMT today it is accepted. Otherwise it might be postponed to after the release. This means subversion trunk should stay frozen until 15:00 GMT today. Maarten |
From: Maarten B. <sou...@ds...> - 2014-03-30 15:12:25
|
>> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: >>> Hi again Is there any simple way to exclude the non-free directory >>> from being built? It is quite simple in version 3.3 but I cannot >>> build version 3.4. In order to get the package into Debian I need >>> to remove the whole non-free directory and this causes compilation >>> errors. >> >> Maarten, >> >> should we try to sort this out before the release, even if it delays >> the release? >> >> Philipp > > We could. But it will mean at least another week of delay. I'm guessing > about half a week to fix both problems reported by Gudjon and create RC3 > and then another half week for testing RC3 before the release. > > If nobody objects to the delay before 15:00 GMT today it is accepted. > Otherwise it might be postponed to after the release. This means > subversion trunk should stay frozen until 15:00 GMT today. > > Maarten Ok, I have not seen any objections so go ahead and try to fix this. I don't think I can be of much help as I know nothing about configure scripts and autotools. At first glance I did see that config.h can be cleaned already with the distclean-hdr target. I have a feeling that 'make distclean' already should clean everything for a distribution. Maarten |
From: Philipp K. K. <pk...@sp...> - 2014-03-30 22:52:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.03.2014 11:22, Maarten Brock wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: >>> Hi again Is there any simple way to exclude the non-free >>> directory from being built? It is quite simple in version 3.3 >>> but I cannot build version 3.4. In order to get the package >>> into Debian I need to remove the whole non-free directory and >>> this causes compilation errors. >> >> Maarten, >> >> should we try to sort this out before the release, even if it >> delays the release? >> >> Philipp > > We could. But it will mean at least another week of delay. I'm > guessing about half a week to fix both problems reported by Gudjon > and create RC3 and then another half week for testing RC3 before > the release. > > If nobody objects to the delay before 15:00 GMT today it is > accepted. Otherwise it might be postponed to after the release. > This means subversion trunk should stay frozen until 15:00 GMT > today. > > Maarten Since we have a delay anyway, I'm wondering if it would be a good idea to merge the sdcc-stm8 branch. It contains one small change in the z80 port, and multiple small changes in the stm8 port, most of them bug fixes. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlM4oDoACgkQbtUV+xsoLpoKdgCeP5aKJPEISHD9/XX5mlMtw4YA odMAniE9u1arNMGxNzMl1w2AIghMtJ/g =020a -----END PGP SIGNATURE----- |
From: Ben S. <pow...@16...> - 2014-03-31 00:53:04
|
I agree, since there are easy-to-find bugs in current RC2's stm8 branch. 在2014年03月31 06时52分,"Philipp Klaus Krause"<pk...@sp...>写道: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.03.2014 11:22, Maarten Brock wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: >>> Hi again Is there any simple way to exclude the non-free >>> directory from being built? It is quite simple in version 3.3 >>> but I cannot build version 3.4. In order to get the package >>> into Debian I need to remove the whole non-free directory and >>> this causes compilation errors. >> >> Maarten, >> >> should we try to sort this out before the release, even if it >> delays the release? >> >> Philipp > > We could. But it will mean at least another week of delay. I'm > guessing about half a week to fix both problems reported by Gudjon > and create RC3 and then another half week for testing RC3 before > the release. > > If nobody objects to the delay before 15:00 GMT today it is > accepted. Otherwise it might be postponed to after the release. > This means subversion trunk should stay frozen until 15:00 GMT > today. > > Maarten Since we have a delay anyway, I'm wondering if it would be a good idea to merge the sdcc-stm8 branch. It contains one small change in the z80 port, and multiple small changes in the stm8 port, most of them bug fixes. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlM4oDoACgkQbtUV+xsoLpoKdgCeP5aKJPEISHD9/XX5mlMtw4YA odMAniE9u1arNMGxNzMl1w2AIghMtJ/g =020a -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ sdcc-devel mailing list sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Maarten B. <sou...@ds...> - 2014-03-31 08:45:10
|
> Since we have a delay anyway, I'm wondering if it would be a good idea > to merge the sdcc-stm8 branch. It contains one small change in the z80 > port, and multiple small changes in the stm8 port, most of them bug fixes. > > Philipp Ok, if it is done today. Maarten |
From: Philipp K. K. <pk...@sp...> - 2014-03-31 09:37:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31.03.2014 10:45, Maarten Brock wrote: >> Since we have a delay anyway, I'm wondering if it would be a good >> idea to merge the sdcc-stm8 branch. It contains one small change >> in the z80 port, and multiple small changes in the stm8 port, >> most of them bug fixes. >> >> Philipp > > Ok, if it is done today. > > Maarten Thanks. It is merged. IMO especially that recently-discovered bug in right shifts of long and long long in registers by 9 or more was important to have fixed before the first release of the stm8 port. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlM5NzUACgkQbtUV+xsoLpqxpwCdGwZr3nDfXcYvcIhWEWRnsKac +sMAn3tCs/ueyxsSVMsBND7onYOE+E8Q =GWAs -----END PGP SIGNATURE----- |
From: Philipp K. K. <pk...@sp...> - 2014-03-30 10:33:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: > Hi again Is there any simple way to exclude the non-free directory > from being built? It is quite simple in version 3.3 but I cannot > build version 3.4. In order to get the package into Debian I need > to remove the whole non-free directory and this causes compilation > errors. > > There are untested Debian packages available for amd64 on deb-src > http://gudjon.org/debian/ source/ deb http://gudjon.org/debian/ > amd64/ > > Please try it but this is a non-free package that has to be > cleaned. > > The gputils version in Debian is ancient. Is some PIC user willing > to take a look at that? > > Regards Gudjon I guess a good solution would be to have a --disable-non-free switch for configure? Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlM38wUACgkQbtUV+xsoLpr/zgCgklknvCf1q8j+3jJ9VxZ3Nxz1 F+wAoOnSlx5Ubd8aasePx4/xMtpHvUDX =jEyn -----END PGP SIGNATURE----- |
From: Philipp K. K. <pk...@sp...> - 2014-03-30 19:02:55
Attachments:
signature.asc
configure.in
|
On 30.03.2014 17:12, Maarten Brock wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: >>>> Hi again Is there any simple way to exclude the non-free directory >>>> from being built? It is quite simple in version 3.3 but I cannot >>>> build version 3.4. In order to get the package into Debian I need >>>> to remove the whole non-free directory and this causes compilation >>>> errors. >>> >>> Maarten, >>> >>> should we try to sort this out before the release, even if it delays >>> the release? >>> >>> Philipp >> >> We could. But it will mean at least another week of delay. I'm guessing >> about half a week to fix both problems reported by Gudjon and create RC3 >> and then another half week for testing RC3 before the release. >> >> If nobody objects to the delay before 15:00 GMT today it is accepted. >> Otherwise it might be postponed to after the release. This means >> subversion trunk should stay frozen until 15:00 GMT today. >> >> Maarten > > Ok, I have not seen any objections so go ahead and try to fix this. I > don't think I can be of much help as I know nothing about configure > scripts and autotools. > Me neither. I made some modifications to the top-level configure.in, that might work, but device/lib/pic16/configure.ac references the non-free stuff as well, and I don't know what to do there. Philipp |
From: Philipp K. K. <pk...@sp...> - 2014-03-30 19:11:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.03.2014 21:02, Philipp Klaus Krause wrote: > On 30.03.2014 17:12, Maarten Brock wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: >>>>> Hi again Is there any simple way to exclude the non-free >>>>> directory from being built? It is quite simple in version >>>>> 3.3 but I cannot build version 3.4. In order to get the >>>>> package into Debian I need to remove the whole non-free >>>>> directory and this causes compilation errors. >>>> >>>> Maarten, >>>> >>>> should we try to sort this out before the release, even if it >>>> delays the release? >>>> >>>> Philipp >>> >>> We could. But it will mean at least another week of delay. I'm >>> guessing about half a week to fix both problems reported by >>> Gudjon and create RC3 and then another half week for testing >>> RC3 before the release. >>> >>> If nobody objects to the delay before 15:00 GMT today it is >>> accepted. Otherwise it might be postponed to after the release. >>> This means subversion trunk should stay frozen until 15:00 GMT >>> today. >>> >>> Maarten >> >> Ok, I have not seen any objections so go ahead and try to fix >> this. I don't think I can be of much help as I know nothing about >> configure scripts and autotools. >> > > Me neither. I made some modifications to the top-level > configure.in, that might work, but device/lib/pic16/configure.ac > references the non-free stuff as well, and I don't know what to do > there. The file I attached doesn't really work yet: The non-free headers are still installed when doing a make install, even after configure - --disable-non-free Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlM4bEIACgkQbtUV+xsoLpqWkACgq8IhG7lToTiNKjOk8GYeCCw9 MLMAoNIb2jrQy40shc692h3tIzPSR3SU =WdRU -----END PGP SIGNATURE----- |
From: Raphael N. <rn...@we...> - 2014-03-30 20:17:09
|
Hi, since I setup the pic build scripts back then, I should be able to tweak them to your/our needs. What *exactly* would you want to/must happen when the --disable-non-free configure argument is given? We could just exclude building any PIC stuff (essentially making the switch imply --disable-pic14 and --disable-pic16), or we could build the code generators but no libraries (pretty useless, as not even generic pointer support would be there), or we could build the code generators and the free libraries (which would leave the ports in a hardly usable state). What would be required to be installed/shipped, and what would need to be installed but in some new location (separate non-free hierarchy or the existing non-free hierarchy)? Raphael On Mar 30, 2014 9:03 PM, "Philipp Klaus Krause" <pk...@sp...> wrote: > On 30.03.2014 17:12, Maarten Brock wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: > >>>> Hi again Is there any simple way to exclude the non-free directory > >>>> from being built? It is quite simple in version 3.3 but I cannot > >>>> build version 3.4. In order to get the package into Debian I need > >>>> to remove the whole non-free directory and this causes compilation > >>>> errors. > >>> > >>> Maarten, > >>> > >>> should we try to sort this out before the release, even if it delays > >>> the release? > >>> > >>> Philipp > >> > >> We could. But it will mean at least another week of delay. I'm guessing > >> about half a week to fix both problems reported by Gudjon and create RC3 > >> and then another half week for testing RC3 before the release. > >> > >> If nobody objects to the delay before 15:00 GMT today it is accepted. > >> Otherwise it might be postponed to after the release. This means > >> subversion trunk should stay frozen until 15:00 GMT today. > >> > >> Maarten > > > > Ok, I have not seen any objections so go ahead and try to fix this. I > > don't think I can be of much help as I know nothing about configure > > scripts and autotools. > > > > Me neither. I made some modifications to the top-level configure.in, > that might work, but device/lib/pic16/configure.ac references the > non-free stuff as well, and I don't know what to do there. > > Philipp > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Maarten B. <sou...@ds...> - 2014-03-30 20:56:52
|
Ooh, just in time Raphael. Before I was under the impression that Philipp knew what to change, but apparently not. And neither do I. So I was about to revert my willingness to do an RC3 and postpone this to after the release. Raphael do you have the time and confidence to get this fixed in a few days? I really would like to get the release out the door with all the delays we already suffered. I think the --disable-non-free should build the code generators and the free libraries. Then with free replacements for the non-free parts one can have a working set. A single --disable-non-free option just to replace two others (--disable-picXX-port) seems useless to me. And I also would not want to limit it to the code generator only. I think the current non-free hierarchy should be fine. It should not be too hard to delete the non-free directory before repackaging. But it should of course be possible to build the resulting source tree without errors. And the resulting binary should be able to compile and link without errors as long as it doesn't need any non-free part (probably a useless program). I hope this makes sense. And if you think it's a big or risky job, please say so. Then we just postpone this to after the release. Maarten > Hi, > > since I setup the pic build scripts back then, I should be able to tweak > them to your/our needs. What *exactly* would you want to/must happen when > the --disable-non-free configure argument is given? > We could just exclude building any PIC stuff (essentially making the > switch imply --disable-pic14 and --disable-pic16), > or we could build the code generators but no libraries (pretty useless, as > not even generic pointer support would be there), > or we could build the code generators and the free libraries (which would > leave the ports in a hardly usable state). > > What would be required to be installed/shipped, and what would need to be > installed but in some new location (separate non-free hierarchy or the > existing non-free hierarchy)? > > Raphael > On Mar 30, 2014 9:03 PM, "Philipp Klaus Krause" <pk...@sp...> wrote: > >> On 30.03.2014 17:12, Maarten Brock wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >> >>> Hash: SHA1 >> >>> >> >>> On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: >> >>>> Hi again Is there any simple way to exclude the non-free directory >> >>>> from being built? It is quite simple in version 3.3 but I cannot >> >>>> build version 3.4. In order to get the package into Debian I need >> >>>> to remove the whole non-free directory and this causes compilation >> >>>> errors. >> >>> >> >>> Maarten, >> >>> >> >>> should we try to sort this out before the release, even if it delays >> >>> the release? >> >>> >> >>> Philipp >> >> >> >> We could. But it will mean at least another week of delay. I'm >> guessing >> >> about half a week to fix both problems reported by Gudjon and create >> RC3 >> >> and then another half week for testing RC3 before the release. >> >> >> >> If nobody objects to the delay before 15:00 GMT today it is accepted. >> >> Otherwise it might be postponed to after the release. This means >> >> subversion trunk should stay frozen until 15:00 GMT today. >> >> >> >> Maarten >> > >> > Ok, I have not seen any objections so go ahead and try to fix this. I >> > don't think I can be of much help as I know nothing about configure >> > scripts and autotools. >> > >> >> Me neither. I made some modifications to the top-level configure.in, >> that might work, but device/lib/pic16/configure.ac references the >> non-free stuff as well, and I don't know what to do there. >> >> Philipp |
From: Raphael N. <rn...@we...> - 2014-03-30 22:25:43
|
Hi, apparently I just have to find a way to not build the pic14/16 device libraries if configure (of the top sdcc project) is called with --disable-non-free. I will look into that on Monday evening and report my status late Monday evening. We will then see if we already have a solution or how long it would probably take to get one. We shall then decide how to proceed. Update: As Gudjon had no problems with 3.3, changes to the PIC libraries/build system may not be required - there are no changes in how the PICs use/depend on non-free, were there?!? The code generators for the PICs should be usable (when omitting the --use-non-free sdcc command line option) - with access to the free libraries (libc18f, libm18f, libsdcc), albeit without the device- specific headers and libraries and without the I/O libs, which depend on the device libs. I need to check if the symbols (register names) required by the generated code are available even if the device libraries are not included. If we need replacement libraries to provide the common subset of register symbols, this change will definitely not be available for this release. I'll check that and report my findings. @Gudjon: Can you briefly explain, how sdcc 3.3 was simple to package? What changed towards 3.4 to make packaging the free (i.e., removing the non-free parts) harder? I assume that you delete the non-free directories (especially device/non-free) before configuring and building. I further assume that you pass --disable-pic14 and --disable-pic16 to make that work with 3.3, and that this approach now fails with 3.4 because compilation of some other component (which one? another backend?) fails after removing non-free? What would you require/request? Since there was no change w.r.t. the PIC stuff (was there?), maybe whatever Philipp already did suffices? @Philipp: Could you briefly explain what you did in this matter? Are you aware of any non-PIC backend having non-free parts/dependencies there? Have you already removed/replaced/stubbed them when --disable-non-free is given? I can also check most of this myself tonight, but any information in advance would speed things up and maybe even avoid unnecessary changes regarding this topic. Good night, Raphael Ooh, just in time Raphael. Before I was under the impression that Philipp knew what to change, but apparently not. And neither do I. So I was about to revert my willingness to do an RC3 and postpone this to after the release. Raphael do you have the time and confidence to get this fixed in a few days? I really would like to get the release out the door with all the delays we already suffered. I think the --disable-non-free should build the code generators and the free libraries. Then with free replacements for the non-free parts one can have a working set. A single --disable-non-free option just to replace two others (--disable-picXX-port) seems useless to me. And I also would not want to limit it to the code generator only. I think the current non-free hierarchy should be fine. It should not be too hard to delete the non-free directory before repackaging. But it should of course be possible to build the resulting source tree without errors. And the resulting binary should be able to compile and link without errors as long as it doesn't need any non-free part (probably a useless program). I hope this makes sense. And if you think it's a big or risky job, please say so. Then we just postpone this to after the release. Maarten > Hi, > > since I setup the pic build scripts back then, I should be able to tweak > them to your/our needs. What *exactly* would you want to/must happen when > the --disable-non-free configure argument is given? > We could just exclude building any PIC stuff (essentially making the > switch imply --disable-pic14 and --disable-pic16), > or we could build the code generators but no libraries (pretty useless, as > not even generic pointer support would be there), > or we could build the code generators and the free libraries (which would > leave the ports in a hardly usable state). > > What would be required to be installed/shipped, and what would need to be > installed but in some new location (separate non-free hierarchy or the > existing non-free hierarchy)? > > Raphael > On Mar 30, 2014 9:03 PM, "Philipp Klaus Krause" <pk...@sp...> wrote: > >> On 30.03.2014 17:12, Maarten Brock wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >> >>> Hash: SHA1 >> >>> >> >>> On 30.03.2014 10:23, Gudjon I. Gudjonsson wrote: >> >>>> Hi again Is there any simple way to exclude the non-free directory >> >>>> from being built? It is quite simple in version 3.3 but I cannot >> >>>> build version 3.4. In order to get the package into Debian I need >> >>>> to remove the whole non-free directory and this causes compilation >> >>>> errors. >> >>> >> >>> Maarten, >> >>> >> >>> should we try to sort this out before the release, even if it delays >> >>> the release? >> >>> >> >>> Philipp >> >> >> >> We could. But it will mean at least another week of delay. I'm >> guessing >> >> about half a week to fix both problems reported by Gudjon and create >> RC3 >> >> and then another half week for testing RC3 before the release. >> >> >> >> If nobody objects to the delay before 15:00 GMT today it is accepted. >> >> Otherwise it might be postponed to after the release. This means >> >> subversion trunk should stay frozen until 15:00 GMT today. >> >> >> >> Maarten >> > >> > Ok, I have not seen any objections so go ahead and try to fix this. I >> > don't think I can be of much help as I know nothing about configure >> > scripts and autotools. >> > >> >> Me neither. I made some modifications to the top-level configure.in, >> that might work, but device/lib/pic16/configure.ac references the >> non-free stuff as well, and I don't know what to do there. >> >> Philipp ------------------------------------------------------------------------------ _______________________________________________ sdcc-devel mailing list sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Philipp K. K. <pk...@sp...> - 2014-03-30 22:49:07
Attachments:
configure.in
Makefile.in
|
On 31.03.2014 00:25, Raphael Neider wrote: > Hi, > > apparently I just have to find a way to not build the pic14/16 device > libraries if configure (of the top sdcc project) is called with > --disable-non-free. I will look into that on Monday evening and report > my status late Monday evening. We will then see if we already have a > solution or how long it would probably take to get one. We shall then > decide how to proceed. > > Update: As Gudjon had no problems with 3.3, changes to the PIC > libraries/build system may not be required - there are no changes in how > the PICs use/depend on non-free, were there?!? > The code generators for the PICs should be usable (when omitting the > --use-non-free sdcc command line option) - with access to the free > libraries (libc18f, libm18f, libsdcc), albeit without the device- > specific headers and libraries and without the I/O libs, which depend on > the device libs. > I need to check if the symbols (register names) required by the > generated code are available even if the device libraries are not > included. If we need replacement libraries to provide the common subset > of register symbols, this change will definitely not be available for > this release. I'll check that and report my findings. > > @Gudjon: Can you briefly explain, how sdcc 3.3 was simple to package? > What changed towards 3.4 to make packaging the free (i.e., removing the > non-free parts) harder? > I assume that you delete the non-free directories (especially > device/non-free) before configuring and building. I further assume that > you pass --disable-pic14 and --disable-pic16 to make that work with 3.3, > and that this approach now fails with 3.4 because compilation of some > other component (which one? another backend?) fails after removing non-free? > What would you require/request? > Since there was no change w.r.t. the PIC stuff (was there?), maybe > whatever Philipp already did suffices? > > @Philipp: Could you briefly explain what you did in this matter? > Are you aware of any non-PIC backend having non-free parts/dependencies > there? AFAIK, no non-pic has any non-free stuff. > Have you already removed/replaced/stubbed them when --disable-non-free > is given? I tried to change configure.in and Makefile.in (attached). Since the changes didn't work as intended, I didn't commit anything. Philipp P.S.: IMO, sdcc should build with --disable-non-free when the device/non-free directory isn't even there. |
From: Raphael N. <rn...@we...> - 2014-03-31 23:47:36
|
Hi, I have had a good look at the problem. Getting rid of non-free requires * moving non-free/lib/pic16/{processors.ac,supported-devices.ac,update.sh} to free lib/pic16 ** new way of listing known devices in sdcc/device/lib/pic16/ supported-devices.ac ** create list of known devices in sdcc/device/lib/pic16/update.sh ** access moved scripts from free tree in sdcc/device/non-free/lib/pic16/ configure.ac * disabling lib/pic16/libio because compilation here depends on the non-free includes ** conditionally remove SUBDIR in sdcc/device/lib/pic16/Makefile.am ** pass --disable-non-free condition to Automake in sdcc/device/lib/pic16/ configure.ac * slightly more than the chahnges to sdcc/Makefile.in and sdcc/configure.inproposed by Philipp * and a freshly generated build system using automake-1.11, aclocal-1.11, and autoreconf2.64. I would now vote against including this in the release due the high risk (or low benefit when limiting this to non-risky changes). So, I propose to proceed with the release as planned and come back to Gudjon and the non-free topic only after the release. I'll continue working on this after the release and check it in when it's done. While looking into this, I found that the device/lib build-system is not well suited for parallel execution: it copies over .asm files from srcdir to . and deletes them afterwards. When running massively parallel, these files seem to be copied over and deleted for various memory models (?), and might be removed by one job before having been used by another, or they might be removed before being removed from another job (which complains/errors out due to the use of plain "rm" instead of "rm -f" when the to-be-removed file is already gone). That should also be looked into and eventually fixed -- but not now. Good night, Raphael On Mon, Mar 31, 2014 at 12:48 AM, Philipp Klaus Krause <pk...@sp...> wrote: > On 31.03.2014 00:25, Raphael Neider wrote: > > Hi, > > > > apparently I just have to find a way to not build the pic14/16 device > > libraries if configure (of the top sdcc project) is called with > > --disable-non-free. I will look into that on Monday evening and report > > my status late Monday evening. We will then see if we already have a > > solution or how long it would probably take to get one. We shall then > > decide how to proceed. > > > > Update: As Gudjon had no problems with 3.3, changes to the PIC > > libraries/build system may not be required - there are no changes in how > > the PICs use/depend on non-free, were there?!? > > The code generators for the PICs should be usable (when omitting the > > --use-non-free sdcc command line option) - with access to the free > > libraries (libc18f, libm18f, libsdcc), albeit without the device- > > specific headers and libraries and without the I/O libs, which depend on > > the device libs. > > I need to check if the symbols (register names) required by the > > generated code are available even if the device libraries are not > > included. If we need replacement libraries to provide the common subset > > of register symbols, this change will definitely not be available for > > this release. I'll check that and report my findings. > > > > @Gudjon: Can you briefly explain, how sdcc 3.3 was simple to package? > > What changed towards 3.4 to make packaging the free (i.e., removing the > > non-free parts) harder? > > I assume that you delete the non-free directories (especially > > device/non-free) before configuring and building. I further assume that > > you pass --disable-pic14 and --disable-pic16 to make that work with 3.3, > > and that this approach now fails with 3.4 because compilation of some > > other component (which one? another backend?) fails after removing > non-free? > > What would you require/request? > > Since there was no change w.r.t. the PIC stuff (was there?), maybe > > whatever Philipp already did suffices? > > > > @Philipp: Could you briefly explain what you did in this matter? > > Are you aware of any non-PIC backend having non-free parts/dependencies > > there? > > AFAIK, no non-pic has any non-free stuff. > > > Have you already removed/replaced/stubbed them when --disable-non-free > > is given? > > I tried to change configure.in and Makefile.in (attached). Since the > changes didn't work as intended, I didn't commit anything. > > Philipp > > P.S.: > > IMO, sdcc should build with --disable-non-free when the device/non-free > directory isn't even there. > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Maarten B. <sou...@ds...> - 2014-04-01 20:43:42
|
Hi Raphael, Thanks. I will try to make RC3 tomorrow from the snapshots. Let's hope they work normally. Today I added the dedication to Borut which in my shame I forgot to add before. You explicitly set versions of the tools below. Is that necessary or is any newer version ok? I guess that I only need to run the first line before I do a commit to get a new configure script. And do you mean to say that 'make install' is broken and doesn't install any libraries? Or just that the pic libraries are missing when these --disable options are used? Maarten > Hi, > > here are the configure.in and Makefile.in from Philipp modified to work as > expected. > > svn/sdcc$ AUTOMAKE=automake-1.11 ACLOCAL=aclocal-1.11 autoreconf2.64 -fi > svn/sdcc$ mkdir build && cd build > svn/sdcc/build$ ../configure --disable-non-free --disable-pic14-port > --disable-pic16-port && make -j4 -s && make install > > compiles fine even when svn/sdcc/device/non-free has been removed. It > should yield a free version of SDCC, albeit without the PIC14 and PIC16 > backends. > I did not check the resulting binary/installation; I think all libraries > are missing in the installed location. > > Best regards, > Raphael > > > > On Tue, Apr 1, 2014 at 1:47 AM, Raphael Neider <rn...@we...> wrote: > >> Hi, >> >> I have had a good look at the problem. Getting rid of non-free requires >> >> * moving >> non-free/lib/pic16/{processors.ac,supported-devices.ac,update.sh} >> to free lib/pic16 >> ** new way of listing known devices in sdcc/device/lib/pic16/ >> supported-devices.ac >> ** create list of known devices in sdcc/device/lib/pic16/update.sh >> ** access moved scripts from free tree in >> sdcc/device/non-free/lib/pic16/ >> configure.ac >> * disabling lib/pic16/libio because compilation here depends on the >> non-free includes >> ** conditionally remove SUBDIR in sdcc/device/lib/pic16/Makefile.am >> ** pass --disable-non-free condition to Automake in >> sdcc/device/lib/pic16/ >> configure.ac >> * slightly more than the chahnges to sdcc/Makefile.in and sdcc/ >> configure.in proposed by Philipp >> * and a freshly generated build system using automake-1.11, >> aclocal-1.11, >> and autoreconf2.64. >> >> I would now vote against including this in the release due the high risk >> (or low benefit when limiting this to non-risky changes). >> So, I propose to proceed with the release as planned and come back to >> Gudjon and the non-free topic only after the release. >> I'll continue working on this after the release and check it in when >> it's >> done. >> >> >> While looking into this, I found that the device/lib build-system is not >> well suited for parallel execution: it copies over .asm files from >> srcdir >> to . and deletes them afterwards. When running massively parallel, these >> files seem to be copied over and deleted for various memory models (?), >> and >> might be removed by one job before having been used by another, or they >> might be removed before being removed from another job (which >> complains/errors out due to the use of plain "rm" instead of "rm -f" >> when >> the to-be-removed file is already gone). That should also be looked into >> and eventually fixed -- but not now. >> >> Good night, >> Raphael >> >> >> >> >> On Mon, Mar 31, 2014 at 12:48 AM, Philipp Klaus Krause >> <pk...@sp...>wrote: >> >>> On 31.03.2014 00:25, Raphael Neider wrote: >>> > Hi, >>> > >>> > apparently I just have to find a way to not build the pic14/16 device >>> > libraries if configure (of the top sdcc project) is called with >>> > --disable-non-free. I will look into that on Monday evening and >>> report >>> > my status late Monday evening. We will then see if we already have a >>> > solution or how long it would probably take to get one. We shall then >>> > decide how to proceed. >>> > >>> > Update: As Gudjon had no problems with 3.3, changes to the PIC >>> > libraries/build system may not be required - there are no changes in >>> how >>> > the PICs use/depend on non-free, were there?!? >>> > The code generators for the PICs should be usable (when omitting the >>> > --use-non-free sdcc command line option) - with access to the free >>> > libraries (libc18f, libm18f, libsdcc), albeit without the device- >>> > specific headers and libraries and without the I/O libs, which depend >>> on >>> > the device libs. >>> > I need to check if the symbols (register names) required by the >>> > generated code are available even if the device libraries are not >>> > included. If we need replacement libraries to provide the common >>> subset >>> > of register symbols, this change will definitely not be available for >>> > this release. I'll check that and report my findings. >>> > >>> > @Gudjon: Can you briefly explain, how sdcc 3.3 was simple to package? >>> > What changed towards 3.4 to make packaging the free (i.e., removing >>> the >>> > non-free parts) harder? >>> > I assume that you delete the non-free directories (especially >>> > device/non-free) before configuring and building. I further assume >>> that >>> > you pass --disable-pic14 and --disable-pic16 to make that work with >>> 3.3, >>> > and that this approach now fails with 3.4 because compilation of some >>> > other component (which one? another backend?) fails after removing >>> non-free? >>> > What would you require/request? >>> > Since there was no change w.r.t. the PIC stuff (was there?), maybe >>> > whatever Philipp already did suffices? >>> > >>> > @Philipp: Could you briefly explain what you did in this matter? >>> > Are you aware of any non-PIC backend having non-free >>> parts/dependencies >>> > there? >>> >>> AFAIK, no non-pic has any non-free stuff. >>> >>> > Have you already removed/replaced/stubbed them when >>> --disable-non-free >>> > is given? >>> >>> I tried to change configure.in and Makefile.in (attached). Since the >>> changes didn't work as intended, I didn't commit anything. >>> >>> Philipp >>> >>> P.S.: >>> >>> IMO, sdcc should build with --disable-non-free when the device/non-free >>> directory isn't even there. >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> sdcc-devel mailing list >>> sdc...@li... >>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >>> >>> >> > ------------------------------------------------------------------------------ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Maarten B. <sou...@ds...> - 2014-04-01 21:08:17
|
What I also don't quite get is if you meant to have these files included or postponed for inclusion? I get the feeling that they build a fully free SDCC when configured with only --disable-non-free. Or are you saying that it can't even build the free libraries for the pics and you thus need to disable these too? Maarten > Hi Raphael, > > Thanks. I will try to make RC3 tomorrow from the snapshots. Let's hope > they work normally. Today I added the dedication to Borut which in my > shame I forgot to add before. > > You explicitly set versions of the tools below. Is that necessary or is > any newer version ok? I guess that I only need to run the first line > before I do a commit to get a new configure script. > > And do you mean to say that 'make install' is broken and doesn't install > any libraries? Or just that the pic libraries are missing when these > --disable options are used? > > Maarten > >> Hi, >> >> here are the configure.in and Makefile.in from Philipp modified to work >> as >> expected. >> >> svn/sdcc$ AUTOMAKE=automake-1.11 ACLOCAL=aclocal-1.11 autoreconf2.64 -fi >> svn/sdcc$ mkdir build && cd build >> svn/sdcc/build$ ../configure --disable-non-free --disable-pic14-port >> --disable-pic16-port && make -j4 -s && make install >> >> compiles fine even when svn/sdcc/device/non-free has been removed. It >> should yield a free version of SDCC, albeit without the PIC14 and PIC16 >> backends. >> I did not check the resulting binary/installation; I think all libraries >> are missing in the installed location. >> >> Best regards, >> Raphael >> >> >> >> On Tue, Apr 1, 2014 at 1:47 AM, Raphael Neider <rn...@we...> wrote: >> >>> Hi, >>> >>> I have had a good look at the problem. Getting rid of non-free requires >>> >>> * moving >>> non-free/lib/pic16/{processors.ac,supported-devices.ac,update.sh} >>> to free lib/pic16 >>> ** new way of listing known devices in sdcc/device/lib/pic16/ >>> supported-devices.ac >>> ** create list of known devices in sdcc/device/lib/pic16/update.sh >>> ** access moved scripts from free tree in >>> sdcc/device/non-free/lib/pic16/ >>> configure.ac >>> * disabling lib/pic16/libio because compilation here depends on the >>> non-free includes >>> ** conditionally remove SUBDIR in sdcc/device/lib/pic16/Makefile.am >>> ** pass --disable-non-free condition to Automake in >>> sdcc/device/lib/pic16/ >>> configure.ac >>> * slightly more than the chahnges to sdcc/Makefile.in and sdcc/ >>> configure.in proposed by Philipp >>> * and a freshly generated build system using automake-1.11, >>> aclocal-1.11, >>> and autoreconf2.64. >>> >>> I would now vote against including this in the release due the high >>> risk >>> (or low benefit when limiting this to non-risky changes). >>> So, I propose to proceed with the release as planned and come back to >>> Gudjon and the non-free topic only after the release. >>> I'll continue working on this after the release and check it in when >>> it's >>> done. >>> >>> >>> While looking into this, I found that the device/lib build-system is >>> not >>> well suited for parallel execution: it copies over .asm files from >>> srcdir >>> to . and deletes them afterwards. When running massively parallel, >>> these >>> files seem to be copied over and deleted for various memory models (?), >>> and >>> might be removed by one job before having been used by another, or they >>> might be removed before being removed from another job (which >>> complains/errors out due to the use of plain "rm" instead of "rm -f" >>> when >>> the to-be-removed file is already gone). That should also be looked >>> into >>> and eventually fixed -- but not now. >>> >>> Good night, >>> Raphael >>> >>> >>> >>> >>> On Mon, Mar 31, 2014 at 12:48 AM, Philipp Klaus Krause >>> <pk...@sp...>wrote: >>> >>>> On 31.03.2014 00:25, Raphael Neider wrote: >>>> > Hi, >>>> > >>>> > apparently I just have to find a way to not build the pic14/16 >>>> device >>>> > libraries if configure (of the top sdcc project) is called with >>>> > --disable-non-free. I will look into that on Monday evening and >>>> report >>>> > my status late Monday evening. We will then see if we already have a >>>> > solution or how long it would probably take to get one. We shall >>>> then >>>> > decide how to proceed. >>>> > >>>> > Update: As Gudjon had no problems with 3.3, changes to the PIC >>>> > libraries/build system may not be required - there are no changes in >>>> how >>>> > the PICs use/depend on non-free, were there?!? >>>> > The code generators for the PICs should be usable (when omitting the >>>> > --use-non-free sdcc command line option) - with access to the free >>>> > libraries (libc18f, libm18f, libsdcc), albeit without the device- >>>> > specific headers and libraries and without the I/O libs, which >>>> depend >>>> on >>>> > the device libs. >>>> > I need to check if the symbols (register names) required by the >>>> > generated code are available even if the device libraries are not >>>> > included. If we need replacement libraries to provide the common >>>> subset >>>> > of register symbols, this change will definitely not be available >>>> for >>>> > this release. I'll check that and report my findings. >>>> > >>>> > @Gudjon: Can you briefly explain, how sdcc 3.3 was simple to >>>> package? >>>> > What changed towards 3.4 to make packaging the free (i.e., removing >>>> the >>>> > non-free parts) harder? >>>> > I assume that you delete the non-free directories (especially >>>> > device/non-free) before configuring and building. I further assume >>>> that >>>> > you pass --disable-pic14 and --disable-pic16 to make that work with >>>> 3.3, >>>> > and that this approach now fails with 3.4 because compilation of >>>> some >>>> > other component (which one? another backend?) fails after removing >>>> non-free? >>>> > What would you require/request? >>>> > Since there was no change w.r.t. the PIC stuff (was there?), maybe >>>> > whatever Philipp already did suffices? >>>> > >>>> > @Philipp: Could you briefly explain what you did in this matter? >>>> > Are you aware of any non-PIC backend having non-free >>>> parts/dependencies >>>> > there? >>>> >>>> AFAIK, no non-pic has any non-free stuff. >>>> >>>> > Have you already removed/replaced/stubbed them when >>>> --disable-non-free >>>> > is given? >>>> >>>> I tried to change configure.in and Makefile.in (attached). Since the >>>> changes didn't work as intended, I didn't commit anything. >>>> >>>> Philipp >>>> >>>> P.S.: >>>> >>>> IMO, sdcc should build with --disable-non-free when the >>>> device/non-free >>>> directory isn't even there. >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> sdcc-devel mailing list >>>> sdc...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >>>> >>>> >>> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> sdcc-devel mailing list >> sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Maarten B. <sou...@ds...> - 2014-04-01 21:17:02
|
Finally I have the feeling that Makefile.in is missing the following line at line 84: PKGS += device/lib Maarten > What I also don't quite get is if you meant to have these files included > or postponed for inclusion? > > I get the feeling that they build a fully free SDCC when configured with > only --disable-non-free. Or are you saying that it can't even build the > free libraries for the pics and you thus need to disable these too? > > Maarten > >> Hi Raphael, >> >> Thanks. I will try to make RC3 tomorrow from the snapshots. Let's hope >> they work normally. Today I added the dedication to Borut which in my >> shame I forgot to add before. >> >> You explicitly set versions of the tools below. Is that necessary or is >> any newer version ok? I guess that I only need to run the first line >> before I do a commit to get a new configure script. >> >> And do you mean to say that 'make install' is broken and doesn't install >> any libraries? Or just that the pic libraries are missing when these >> --disable options are used? >> >> Maarten >> >>> Hi, >>> >>> here are the configure.in and Makefile.in from Philipp modified to work >>> as >>> expected. >>> >>> svn/sdcc$ AUTOMAKE=automake-1.11 ACLOCAL=aclocal-1.11 autoreconf2.64 >>> -fi >>> svn/sdcc$ mkdir build && cd build >>> svn/sdcc/build$ ../configure --disable-non-free --disable-pic14-port >>> --disable-pic16-port && make -j4 -s && make install >>> >>> compiles fine even when svn/sdcc/device/non-free has been removed. It >>> should yield a free version of SDCC, albeit without the PIC14 and PIC16 >>> backends. >>> I did not check the resulting binary/installation; I think all >>> libraries >>> are missing in the installed location. >>> >>> Best regards, >>> Raphael >>> >>> >>> >>> On Tue, Apr 1, 2014 at 1:47 AM, Raphael Neider <rn...@we...> wrote: >>> >>>> Hi, >>>> >>>> I have had a good look at the problem. Getting rid of non-free >>>> requires >>>> >>>> * moving >>>> non-free/lib/pic16/{processors.ac,supported-devices.ac,update.sh} >>>> to free lib/pic16 >>>> ** new way of listing known devices in sdcc/device/lib/pic16/ >>>> supported-devices.ac >>>> ** create list of known devices in sdcc/device/lib/pic16/update.sh >>>> ** access moved scripts from free tree in >>>> sdcc/device/non-free/lib/pic16/ >>>> configure.ac >>>> * disabling lib/pic16/libio because compilation here depends on the >>>> non-free includes >>>> ** conditionally remove SUBDIR in sdcc/device/lib/pic16/Makefile.am >>>> ** pass --disable-non-free condition to Automake in >>>> sdcc/device/lib/pic16/ >>>> configure.ac >>>> * slightly more than the chahnges to sdcc/Makefile.in and sdcc/ >>>> configure.in proposed by Philipp >>>> * and a freshly generated build system using automake-1.11, >>>> aclocal-1.11, >>>> and autoreconf2.64. >>>> >>>> I would now vote against including this in the release due the high >>>> risk >>>> (or low benefit when limiting this to non-risky changes). >>>> So, I propose to proceed with the release as planned and come back to >>>> Gudjon and the non-free topic only after the release. >>>> I'll continue working on this after the release and check it in when >>>> it's >>>> done. >>>> >>>> >>>> While looking into this, I found that the device/lib build-system is >>>> not >>>> well suited for parallel execution: it copies over .asm files from >>>> srcdir >>>> to . and deletes them afterwards. When running massively parallel, >>>> these >>>> files seem to be copied over and deleted for various memory models >>>> (?), >>>> and >>>> might be removed by one job before having been used by another, or >>>> they >>>> might be removed before being removed from another job (which >>>> complains/errors out due to the use of plain "rm" instead of "rm -f" >>>> when >>>> the to-be-removed file is already gone). That should also be looked >>>> into >>>> and eventually fixed -- but not now. >>>> >>>> Good night, >>>> Raphael >>>> >>>> >>>> >>>> >>>> On Mon, Mar 31, 2014 at 12:48 AM, Philipp Klaus Krause >>>> <pk...@sp...>wrote: >>>> >>>>> On 31.03.2014 00:25, Raphael Neider wrote: >>>>> > Hi, >>>>> > >>>>> > apparently I just have to find a way to not build the pic14/16 >>>>> device >>>>> > libraries if configure (of the top sdcc project) is called with >>>>> > --disable-non-free. I will look into that on Monday evening and >>>>> report >>>>> > my status late Monday evening. We will then see if we already have >>>>> a >>>>> > solution or how long it would probably take to get one. We shall >>>>> then >>>>> > decide how to proceed. >>>>> > >>>>> > Update: As Gudjon had no problems with 3.3, changes to the PIC >>>>> > libraries/build system may not be required - there are no changes >>>>> in >>>>> how >>>>> > the PICs use/depend on non-free, were there?!? >>>>> > The code generators for the PICs should be usable (when omitting >>>>> the >>>>> > --use-non-free sdcc command line option) - with access to the free >>>>> > libraries (libc18f, libm18f, libsdcc), albeit without the device- >>>>> > specific headers and libraries and without the I/O libs, which >>>>> depend >>>>> on >>>>> > the device libs. >>>>> > I need to check if the symbols (register names) required by the >>>>> > generated code are available even if the device libraries are not >>>>> > included. If we need replacement libraries to provide the common >>>>> subset >>>>> > of register symbols, this change will definitely not be available >>>>> for >>>>> > this release. I'll check that and report my findings. >>>>> > >>>>> > @Gudjon: Can you briefly explain, how sdcc 3.3 was simple to >>>>> package? >>>>> > What changed towards 3.4 to make packaging the free (i.e., removing >>>>> the >>>>> > non-free parts) harder? >>>>> > I assume that you delete the non-free directories (especially >>>>> > device/non-free) before configuring and building. I further assume >>>>> that >>>>> > you pass --disable-pic14 and --disable-pic16 to make that work with >>>>> 3.3, >>>>> > and that this approach now fails with 3.4 because compilation of >>>>> some >>>>> > other component (which one? another backend?) fails after removing >>>>> non-free? >>>>> > What would you require/request? >>>>> > Since there was no change w.r.t. the PIC stuff (was there?), maybe >>>>> > whatever Philipp already did suffices? >>>>> > >>>>> > @Philipp: Could you briefly explain what you did in this matter? >>>>> > Are you aware of any non-PIC backend having non-free >>>>> parts/dependencies >>>>> > there? >>>>> >>>>> AFAIK, no non-pic has any non-free stuff. >>>>> >>>>> > Have you already removed/replaced/stubbed them when >>>>> --disable-non-free >>>>> > is given? >>>>> >>>>> I tried to change configure.in and Makefile.in (attached). Since the >>>>> changes didn't work as intended, I didn't commit anything. >>>>> >>>>> Philipp >>>>> >>>>> P.S.: >>>>> >>>>> IMO, sdcc should build with --disable-non-free when the >>>>> device/non-free >>>>> directory isn't even there. >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> sdcc-devel mailing list >>>>> sdc...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >>>>> >>>>> >>>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> sdcc-devel mailing list >>> sdc...@li... >>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >>> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> sdcc-devel mailing list >> sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Raphael N. <rn...@we...> - 2014-04-01 21:21:08
|
Hi Maarten, Finally I have the feeling that Makefile.in is missing the following line > at line 84: > PKGS += device/lib > > That's right! I probably removed that by accident and just did two full builds to see them fail to install any libraries :-(. Thanks for the pointer. I'll answer your previous mails in a minute. Raphael |
From: Raphael N. <rn...@we...> - 2014-04-01 21:35:39
|
Hi, On Tue, Apr 1, 2014 at 11:08 PM, Maarten Brock <sou...@ds...>wrote: > What I also don't quite get is if you meant to have these files included > or postponed for inclusion? > > I get the feeling that they build a fully free SDCC when configured with > only --disable-non-free. Or are you saying that it can't even build the > free libraries for the pics and you thus need to disable these too? > Exactly. --disable-non-free prevents the non-free device libraries (libdev<part-number>.lib) for the PIC ports from being built. It does *not* (yet) prevent the free lib/pic16/libio from accessing the non-free header files during building. While this works and probably results in free software, the resulting libio is probably useless without the libdev18f6720.lib or whatever target device one is using due to undefined symbols for SFRs. I do not know how strict the Debian rules w.r.t. free software are, and if Gudjon actually removes/renames device/non-free before building. With --disable-non-free (and, for now, --disable-pic14-port --disable-pic16-port) he could do that and build a completely free sdcc (without the PIC backends). Giving only --disable-non-free will currently still fail if device/non-free is removed/renamed before the build because at least pic16 accesses non-free/... during compilation of free libs. Changing this requires some changes that I would not commit at this point in time just before a release. I thus would include the configure.in and Makefile.in (including your fix) since they do not break anything but give Gudjon a good chance of creating a free SDCC release for Debian with little effort. Adding the free parts of the PIC backends later should still be possible. Raphael |
From: Maarten B. <sou...@ds...> - 2014-04-01 21:58:09
|
Thanks for the clarification. I'm still not sure if I need those exact versions. But it seems to fail if I don't. After running autoreconf I have lots of modified files. Is that right and do I have to commit them all? As you can see, I have never done this. Maarten > Hi, > > On Tue, Apr 1, 2014 at 11:08 PM, Maarten Brock > <sou...@ds...>wrote: > >> What I also don't quite get is if you meant to have these files included >> or postponed for inclusion? >> >> I get the feeling that they build a fully free SDCC when configured with >> only --disable-non-free. Or are you saying that it can't even build the >> free libraries for the pics and you thus need to disable these too? >> > > Exactly. > > --disable-non-free prevents the non-free device libraries > (libdev<part-number>.lib) for the PIC ports from being built. It does > *not* > (yet) prevent the free lib/pic16/libio from accessing the non-free header > files during building. While this works and probably results in free > software, the resulting libio is probably useless without the > libdev18f6720.lib or whatever target device one is using due to undefined > symbols for SFRs. > > I do not know how strict the Debian rules w.r.t. free software are, and if > Gudjon actually removes/renames device/non-free before building. With > --disable-non-free (and, for now, --disable-pic14-port > --disable-pic16-port) he could do that and build a completely free sdcc > (without the PIC backends). > Giving only --disable-non-free will currently still fail if > device/non-free > is removed/renamed before the build because at least pic16 accesses > non-free/... during compilation of free libs. Changing this requires some > changes that I would not commit at this point in time just before a > release. > > I thus would include the configure.in and Makefile.in (including your fix) > since they do not break anything but give Gudjon a good chance of creating > a free SDCC release for Debian with little effort. Adding the free parts > of > the PIC backends later should still be possible. > > Raphael > ------------------------------------------------------------------------------ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Raphael N. <rn...@we...> - 2014-04-01 21:58:35
|
Hi, On Tue, Apr 1, 2014 at 10:43 PM, Maarten Brock <sou...@ds...>wrote: > Hi Raphael, > > Thanks. I will try to make RC3 tomorrow from the snapshots. Let's hope > they work normally. Today I added the dedication to Borut which in my > shame I forgot to add before. > > You explicitly set versions of the tools below. Is that necessary or is > any newer version ok? I guess that I only need to run the first line > before I do a commit to get a new configure script. > We *need* to use autoconf 2.64, because the included binutils require exactly that specific version. I had automake 1.13 (and aclocal 1.13) installed on my machine, and they fail because they in turn require autoconf >= 2.65 (or was it >= 2.69?), so just running autoreconf2.64 did not work for me. automake 1.12 was not released (as far I can tell, at least, it's not available in Xubuntu by default), so I guess the best we can do is use automake 1.11. I think I also tried 1.10, but do not clearly remember :-(. So, yes: If something goes wrong in your setup, try installing and using the versions given below, other combinations are likely to fail. Yes, the first line is sufficient to re-generate the build system (configure.{ac,in} => configure, (Makefile.am =>) Makefile.in => Makefile in various places). And do you mean to say that 'make install' is broken and doesn't install > any libraries? Or just that the pic libraries are missing when these > --disable options are used? > When I used 'make install', all I got was binaries in bin/*, documentation in share/doc/{ucsim,sdcc}/*, and headers in share/sdcc/include/{mcs51,hc08}/*, share/sdcc/include/asm/*/* (plus lib/libiberty.a). But you fixed that in Makefile.in, so that was probably my fault. I still do not get any PIC14/16 libraries installed with sdcc.svn$ mkdir b sdcc.svn$ cd b sdcc.svn/b$ ../sdcc/configure --prefix=/media/data/sdcc-20140401c && make -j3 -s && make install but at least the other ports' libs seem to be there, which is the important thing for the release. (PIC backend users probably have to/had to build from source or use snapshots anyways, and that can still be fixed). For the pic ports, I do get a lot of library archives such as /media/data/sdcc-20140401c/share/sdcc/lib/src/pic16/libio/libio18f4321.a installed (which should not be -- they should be libio18f4321.lib and should be copied into non-free/lib/pic16/), which needs some looking into and fixing, but also probably not before the release. I'll go and retest with the original configure.in and Makefile.in if installing PIC libraries is working there. Raphael > > Hi, > > > > here are the configure.in and Makefile.in from Philipp modified to work > as > > expected. > > > > svn/sdcc$ AUTOMAKE=automake-1.11 ACLOCAL=aclocal-1.11 autoreconf2.64 -fi > > svn/sdcc$ mkdir build && cd build > > svn/sdcc/build$ ../configure --disable-non-free --disable-pic14-port > > --disable-pic16-port && make -j4 -s && make install > > > > compiles fine even when svn/sdcc/device/non-free has been removed. It > > should yield a free version of SDCC, albeit without the PIC14 and PIC16 > > backends. > > I did not check the resulting binary/installation; I think all libraries > > are missing in the installed location. > > > > Best regards, > > Raphael > > > > > > > > On Tue, Apr 1, 2014 at 1:47 AM, Raphael Neider <rn...@we...> wrote: > > > >> Hi, > >> > >> I have had a good look at the problem. Getting rid of non-free requires > >> > >> * moving > >> non-free/lib/pic16/{processors.ac,supported-devices.ac,update.sh} > >> to free lib/pic16 > >> ** new way of listing known devices in sdcc/device/lib/pic16/ > >> supported-devices.ac > >> ** create list of known devices in sdcc/device/lib/pic16/update.sh > >> ** access moved scripts from free tree in > >> sdcc/device/non-free/lib/pic16/ > >> configure.ac > >> * disabling lib/pic16/libio because compilation here depends on the > >> non-free includes > >> ** conditionally remove SUBDIR in sdcc/device/lib/pic16/Makefile.am > >> ** pass --disable-non-free condition to Automake in > >> sdcc/device/lib/pic16/ > >> configure.ac > >> * slightly more than the chahnges to sdcc/Makefile.in and sdcc/ > >> configure.in proposed by Philipp > >> * and a freshly generated build system using automake-1.11, > >> aclocal-1.11, > >> and autoreconf2.64. > >> > >> I would now vote against including this in the release due the high risk > >> (or low benefit when limiting this to non-risky changes). > >> So, I propose to proceed with the release as planned and come back to > >> Gudjon and the non-free topic only after the release. > >> I'll continue working on this after the release and check it in when > >> it's > >> done. > >> > >> > >> While looking into this, I found that the device/lib build-system is not > >> well suited for parallel execution: it copies over .asm files from > >> srcdir > >> to . and deletes them afterwards. When running massively parallel, these > >> files seem to be copied over and deleted for various memory models (?), > >> and > >> might be removed by one job before having been used by another, or they > >> might be removed before being removed from another job (which > >> complains/errors out due to the use of plain "rm" instead of "rm -f" > >> when > >> the to-be-removed file is already gone). That should also be looked into > >> and eventually fixed -- but not now. > >> > >> Good night, > >> Raphael > >> > >> > >> > >> > >> On Mon, Mar 31, 2014 at 12:48 AM, Philipp Klaus Krause > >> <pk...@sp...>wrote: > >> > >>> On 31.03.2014 00:25, Raphael Neider wrote: > >>> > Hi, > >>> > > >>> > apparently I just have to find a way to not build the pic14/16 device > >>> > libraries if configure (of the top sdcc project) is called with > >>> > --disable-non-free. I will look into that on Monday evening and > >>> report > >>> > my status late Monday evening. We will then see if we already have a > >>> > solution or how long it would probably take to get one. We shall then > >>> > decide how to proceed. > >>> > > >>> > Update: As Gudjon had no problems with 3.3, changes to the PIC > >>> > libraries/build system may not be required - there are no changes in > >>> how > >>> > the PICs use/depend on non-free, were there?!? > >>> > The code generators for the PICs should be usable (when omitting the > >>> > --use-non-free sdcc command line option) - with access to the free > >>> > libraries (libc18f, libm18f, libsdcc), albeit without the device- > >>> > specific headers and libraries and without the I/O libs, which depend > >>> on > >>> > the device libs. > >>> > I need to check if the symbols (register names) required by the > >>> > generated code are available even if the device libraries are not > >>> > included. If we need replacement libraries to provide the common > >>> subset > >>> > of register symbols, this change will definitely not be available for > >>> > this release. I'll check that and report my findings. > >>> > > >>> > @Gudjon: Can you briefly explain, how sdcc 3.3 was simple to package? > >>> > What changed towards 3.4 to make packaging the free (i.e., removing > >>> the > >>> > non-free parts) harder? > >>> > I assume that you delete the non-free directories (especially > >>> > device/non-free) before configuring and building. I further assume > >>> that > >>> > you pass --disable-pic14 and --disable-pic16 to make that work with > >>> 3.3, > >>> > and that this approach now fails with 3.4 because compilation of some > >>> > other component (which one? another backend?) fails after removing > >>> non-free? > >>> > What would you require/request? > >>> > Since there was no change w.r.t. the PIC stuff (was there?), maybe > >>> > whatever Philipp already did suffices? > >>> > > >>> > @Philipp: Could you briefly explain what you did in this matter? > >>> > Are you aware of any non-PIC backend having non-free > >>> parts/dependencies > >>> > there? > >>> > >>> AFAIK, no non-pic has any non-free stuff. > >>> > >>> > Have you already removed/replaced/stubbed them when > >>> --disable-non-free > >>> > is given? > >>> > >>> I tried to change configure.in and Makefile.in (attached). Since the > >>> changes didn't work as intended, I didn't commit anything. > >>> > >>> Philipp > >>> > >>> P.S.: > >>> > >>> IMO, sdcc should build with --disable-non-free when the device/non-free > >>> directory isn't even there. > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> sdcc-devel mailing list > >>> sdc...@li... > >>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel > >>> > >>> > >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Raphael N. <rn...@we...> - 2014-04-01 22:04:43
|
Hi, On Tue, Apr 1, 2014 at 11:57 PM, Maarten Brock <sou...@ds...> wrote: > Thanks for the clarification. I'm still not sure if I need those exact > versions. But it seems to fail if I don't. > > After running autoreconf I have lots of modified files. Is that right and > do I have to commit them all? As you can see, I have never done this. > I tend to commit the files in two separate commits: first commit the manually edited files (configure.in, Makefile.in or Makefile.am), then commit all automatically regenerated files (configure, Makefile, occasionally Makefile.in). The diff will typically tell you if a particular file was generated or manually edited. This is cumbersome and tedious, but the best I can come up with. The autogeerated files are typically committed with a comment such as "regenerated" or so. We commit those files so that SVN users do not need to have the autotools (in the proper versions) setup. Other projects do include the generated files in releases, but not in source control. It's probably a matter of taste. See e.g., my commits r8697 (manually edited or manually generated files (mkmk.sh)) and r868 (auto-generated files), log below. Raphael ------------------------------------------------------------------------ r8698 | tecodev | 2013-05-30 21:27:39 +0200 (Thu, 30 May 2013) | 14 lines * device/lib/pic16/Makefile.in, * device/lib/pic16/aclocal.m4, * device/lib/pic16/configure, * device/lib/pic16/debug/Makefile.in, * device/lib/pic16/libc/Makefile.in, * device/lib/pic16/libio/Makefile.in, * device/lib/pic16/libm/Makefile.in, * device/lib/pic16/libsdcc/Makefile.in, * device/lib/pic16/startup/Makefile.in, * device/non-free/lib/pic16/Makefile.in, * device/non-free/lib/pic16/aclocal.m4, * device/non-free/lib/pic16/configure, * device/non-free/lib/pic16/libdev/Makefile.in: regenerated ------------------------------------------------------------------------ r8697 | tecodev | 2013-05-30 21:25:40 +0200 (Thu, 30 May 2013) | 34 lines * device/lib/pic16/configure.ac, * device/non-free/lib/pic16/configure.ac: remove obsolete option --enable-new-pics, use common device support detection from supported-devices.ac and the generated processors.ac * device/non-free/lib/pic16/supported-devices.ac: fragment from configure.ac performing detection of devices supported by gputils; device detection also performs linking step for robustness * device/lib/pic16/libio/adc.ignore, * device/lib/pic16/libio/i2c.ignore, * device/lib/pic16/libio/usart.ignore: use full device id (18fxxxx) * device/lib/pic16/libio/mkmk.sh, * device/non-free/lib/pic16/libdev/mkmk.sh, * device/non-free/lib/pic16/libdev/testall.sh: derive device list from files in non-free/lib/pic16/libdev rather than the manually maintained pics.all, enclose each device in ENABLE_<DEVICE> conditionals * device/non-free/lib/pic16/update.sh: script to update the build system to be run whenever the set of devices supported by sdcc changed; generates processor.ac and reconfigures all PIC16 libs * support/scripts/cinc2h.pl: update instructions regarding adding support for new devices * device/lib/pic16/libio/Makefile.am:regenerated from mkmk.sh * device/non-free/lib/pic16/libdev/Makefile.am: regenerated from mkmk.sh * device/non-free/lib/pic16/pics.all: removed (no longer used) * device/non-free/lib/pic16/processors.ac: added, list of automake conditionals for automatic detection of devices supported by gputils, generated from update.sh |