* gprbuild fun @ 2015-06-28 17:28 Simon Wright 2015-06-28 18:09 ` Dmitry A. Kazakov 2015-06-29 9:58 ` Brian Drummond 0 siblings, 2 replies; 14+ messages in thread From: Simon Wright @ 2015-06-28 17:28 UTC (permalink / raw) I have a mixed-language GPR like project build is for languages use ("ada", "c"); for source_files use ("a.adb", "c.c"); package ide is for compiler_command ("ada") use "gnatmake"; end ide; end build; (I have no idea why I introduced the compiler_command setting on 2014-05-01, and I have no idea why the issue has only just surfaced) and, if I have the native gcc and arm-eabi-gcc present in the PATH, gprbuild chooses to use the native gcc for the Ada part and arm-eabi-gcc for the C part! Fix: delete the compiler_command line. _That_ was fun. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-28 17:28 gprbuild fun Simon Wright @ 2015-06-28 18:09 ` Dmitry A. Kazakov 2015-06-28 19:22 ` David Botton 2015-06-28 20:08 ` Simon Wright 2015-06-29 9:58 ` Brian Drummond 1 sibling, 2 replies; 14+ messages in thread From: Dmitry A. Kazakov @ 2015-06-28 18:09 UTC (permalink / raw) On Sun, 28 Jun 2015 18:28:13 +0100, Simon Wright wrote: > I have a mixed-language GPR like > > project build is > for languages use ("ada", "c"); > for source_files use ("a.adb", "c.c"); > package ide is > for compiler_command ("ada") use "gnatmake"; > end ide; > end build; > > (I have no idea why I introduced the compiler_command setting on > 2014-05-01, and I have no idea why the issue has only just surfaced) > > and, if I have the native gcc and arm-eabi-gcc present in the PATH, > gprbuild chooses to use the native gcc for the Ada part and arm-eabi-gcc > for the C part! > > Fix: delete the compiler_command line. Under Fedora ARM gprbuild is broken (wrong target). The fix is to rename it to /usr/bin/gprbuild.old and use #!/bin/sh gprbuild.old --target=armv7hl-redhat-linux-gnueabi $* instead. It is a pity that gnatmake is going to be ditched. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-28 18:09 ` Dmitry A. Kazakov @ 2015-06-28 19:22 ` David Botton 2015-06-28 21:37 ` vincent.diemunsch 2015-06-28 20:08 ` Simon Wright 1 sibling, 1 reply; 14+ messages in thread From: David Botton @ 2015-06-28 19:22 UTC (permalink / raw) No reason not to make a community effort for a set of build tools that is not as "delicate" as the gprtools and requires code outside the FSF tree to be compiled and used. David Botton ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-28 19:22 ` David Botton @ 2015-06-28 21:37 ` vincent.diemunsch 2015-06-28 23:02 ` David Botton 0 siblings, 1 reply; 14+ messages in thread From: vincent.diemunsch @ 2015-06-28 21:37 UTC (permalink / raw) Le dimanche 28 juin 2015 21:22:33 UTC+2, David Botton a écrit : > No reason not to make a community effort for a set of build tools that is not as "delicate" as the gprtools and requires code outside the FSF tree to be compiled and used. > > David Botton Sure. What could be the starting point ? Is gnatmake full FSF ? Could it be possible to add a sort of Ant or Maven written in Ada to replace GPR Build ? On idea : could it be possible to simply write the "makefile" in Ada then compile it first as an executable and use it to launch the rest of the compilation process ? To do that one only needs to develop a "building library" in Ada. No messy XML file required anymore ! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-28 21:37 ` vincent.diemunsch @ 2015-06-28 23:02 ` David Botton 2015-06-29 8:24 ` vincent.diemunsch 2015-06-29 8:29 ` Simon Wright 0 siblings, 2 replies; 14+ messages in thread From: David Botton @ 2015-06-28 23:02 UTC (permalink / raw) > Sure. What could be the starting point ? Is gnatmake full FSF ? Could it be possible to add a sort of Ant or Maven written in Ada to replace GPR Build ? gnatmake is full FSF and part of the FSF tree. Once deprecated unless something changes it will no longer be possible to build an FSF GNAT using FSF tools. As it is, I doubt there will be future Windows 64 builds available already after 4.9.x unless we do something. > On idea : could it be possible to simply write the "makefile" in Ada then compile it first as an executable and use it to launch the rest of the compilation process ? To do that one only needs to develop a "building library" in Ada. No messy XML file required anymore ! I don't think removing all dependencies on ASIS and XML are even a question for any future tool. gnatmake currently does not depend on either. David Botton ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-28 23:02 ` David Botton @ 2015-06-29 8:24 ` vincent.diemunsch 2015-06-29 8:36 ` Simon Wright 2015-06-29 8:29 ` Simon Wright 1 sibling, 1 reply; 14+ messages in thread From: vincent.diemunsch @ 2015-06-29 8:24 UTC (permalink / raw) Le lundi 29 juin 2015 01:02:23 UTC+2, David Botton a écrit : > > Sure. What could be the starting point ? Is gnatmake full FSF ? Could it be possible to add a sort of Ant or Maven written in Ada to replace GPR Build ? > > gnatmake is full FSF and part of the FSF tree. Once deprecated unless something changes it will no longer be possible to build an FSF GNAT using FSF tools. As it is, I doubt there will be future Windows 64 builds available already after 4.9.x unless we do something. So the first priority is to save gnatmake as the FSF tool to build FSF GNAT ! I don't really understand what are the technical improvements of GPR Build over gnatmake. All I know is that even for a simple case of code generation using AYacc, I needed to create a makefile and an XML configuration file to use GPR Build... I thought that if I had a small Ada Library able to manage source files, object files and the equivalent of ".ali" files, I could write directly an Ada program that would call Ayacc and gnatmake, with not more work than creating makefiles and XML files. Regards, Vincent ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-29 8:24 ` vincent.diemunsch @ 2015-06-29 8:36 ` Simon Wright 2015-06-29 8:57 ` Vincent 0 siblings, 1 reply; 14+ messages in thread From: Simon Wright @ 2015-06-29 8:36 UTC (permalink / raw) vincent.diemunsch@gmail.com writes: > So the first priority is to save gnatmake as the FSF tool to build > FSF GNAT ! I don't see this changing; AdaCore aren't proposing to remove any of the features of gnatmake that are actually used in the GCC build. > I don't really understand what are the technical improvements of GPR > Build over gnatmake. All I know is that even for a simple case of code > generation using AYacc, I needed to create a makefile and an XML > configuration file to use GPR Build... So you were able to teach gprbuild how to handle AYacc? sounds good to me! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-29 8:36 ` Simon Wright @ 2015-06-29 8:57 ` Vincent 0 siblings, 0 replies; 14+ messages in thread From: Vincent @ 2015-06-29 8:57 UTC (permalink / raw) Le lundi 29 juin 2015 10:36:55 UTC+2, Simon Wright a écrit : > Vincent wrote : > > > So the first priority is to save gnatmake as the FSF tool to build > > FSF GNAT ! > > I don't see this changing; AdaCore aren't proposing to remove any of the > features of gnatmake that are actually used in the GCC build. Good news ! > > So you were able to teach gprbuild how to handle AYacc? sounds good to > me! No, sorry.. I simply got the response of using a makefile and a XML configuration for a new buildchain. Then I gave up with gprbuild and made a small script :-). That was enough for my need, even it is not satisfactory. vincent ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-28 23:02 ` David Botton 2015-06-29 8:24 ` vincent.diemunsch @ 2015-06-29 8:29 ` Simon Wright 1 sibling, 0 replies; 14+ messages in thread From: Simon Wright @ 2015-06-29 8:29 UTC (permalink / raw) David Botton <david@botton.com> writes: (in response to Vincent. David, could you get your newsreader to include the person you're quoting?) >> Sure. What could be the starting point ? Is gnatmake full FSF ? Could >> it be possible to add a sort of Ant or Maven written in Ada to >> replace GPR Build ? > > gnatmake is full FSF and part of the FSF tree. Once deprecated unless > something changes it will no longer be possible to build an FSF GNAT > using FSF tools. As it is, I doubt there will be future Windows 64 > builds available already after 4.9.x unless we do something. The deprecated parts of gnatmake are the use of GPR project files and the creation of libraries (which gnatmake doesn't do well anyway, at any rate for Mac dylibs). There are no project files in the FSF GCC build process (actually there is one in the GCC tree, zlib/contrib/ada/zlib.gpr, imported from the zlib project, which builds a testbed for the zlib ada binding but isn't used by GCC itself). >> On idea : could it be possible to simply write the "makefile" in Ada >> then compile it first as an executable and use it to launch the rest >> of the compilation process ? To do that one only needs to develop a >> "building library" in Ada. No messy XML file required anymore ! > > I don't think removing all dependencies on ASIS and XML are even a > question for any future tool. gnatmake currently does not depend on > either. We're talking a build tool here, no reason not to use GPL code since the compiler itself is GPL anyway! The only question is the RTS. There's no use of ASIS in gprbuild. XML is used as a handy :) way of holding a complex data structure in text files. It's verbose, sure, and the way it's all put together is reasonably obscure, but what gprbuild does with it is very useful. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-28 18:09 ` Dmitry A. Kazakov 2015-06-28 19:22 ` David Botton @ 2015-06-28 20:08 ` Simon Wright 1 sibling, 0 replies; 14+ messages in thread From: Simon Wright @ 2015-06-28 20:08 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Sun, 28 Jun 2015 18:28:13 +0100, Simon Wright wrote: > >> I have a mixed-language GPR like >> >> project build is >> for languages use ("ada", "c"); >> for source_files use ("a.adb", "c.c"); >> package ide is >> for compiler_command ("ada") use "gnatmake"; >> end ide; >> end build; >> >> (I have no idea why I introduced the compiler_command setting on >> 2014-05-01, and I have no idea why the issue has only just surfaced) I suppose I've only had arm-eabi-gcc on the path fairly recently, so there wouldn't've been a cross-compiler to confuse matters. >> and, if I have the native gcc and arm-eabi-gcc present in the PATH, >> gprbuild chooses to use the native gcc for the Ada part and arm-eabi-gcc >> for the C part! >> >> Fix: delete the compiler_command line. > > Under Fedora ARM gprbuild is broken (wrong target). The fix is to rename it > to /usr/bin/gprbuild.old and use > > #!/bin/sh > gprbuild.old --target=armv7hl-redhat-linux-gnueabi $* > > instead. It is a pity that gnatmake is going to be ditched. In this case, I could alternatively have invoked gprbuild with --target=x86_64-apple-darwin13. But it shouldn't've been necessary! I'm still quite baffled as to exactly where in the source gprbuild invokes gprconfig with --target=all to cause the effect I saw. I suppose it might just call it as a library. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-28 17:28 gprbuild fun Simon Wright 2015-06-28 18:09 ` Dmitry A. Kazakov @ 2015-06-29 9:58 ` Brian Drummond 2015-06-29 10:11 ` Mark Lorenzen 2015-06-29 11:10 ` Simon Wright 1 sibling, 2 replies; 14+ messages in thread From: Brian Drummond @ 2015-06-29 9:58 UTC (permalink / raw) On Sun, 28 Jun 2015 18:28:13 +0100, Simon Wright wrote: > I have a mixed-language GPR like > > project build is > for languages use ("ada", "c"); > for source_files use ("a.adb", "c.c"); > package ide is > for compiler_command ("ada") use "gnatmake"; > end ide; > end build; > and, if I have the native gcc and arm-eabi-gcc present in the PATH, > gprbuild chooses to use the native gcc for the Ada part and arm-eabi-gcc > for the C part! > > Fix: delete the compiler_command line. Presumably, ... editing it to arm-eabi-gnatmake would also work? -- Brian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-29 9:58 ` Brian Drummond @ 2015-06-29 10:11 ` Mark Lorenzen 2015-06-29 11:17 ` Simon Wright 2015-06-29 11:10 ` Simon Wright 1 sibling, 1 reply; 14+ messages in thread From: Mark Lorenzen @ 2015-06-29 10:11 UTC (permalink / raw) On Monday, June 29, 2015 at 11:59:36 AM UTC+2, Brian Drummond wrote: > On Sun, 28 Jun 2015 18:28:13 +0100, Simon Wright wrote: > > > I have a mixed-language GPR like > > > > project build is > > for languages use ("ada", "c"); > > for source_files use ("a.adb", "c.c"); > > package ide is > > for compiler_command ("ada") use "gnatmake"; > > end ide; > > end build; > > > and, if I have the native gcc and arm-eabi-gcc present in the PATH, > > gprbuild chooses to use the native gcc for the Ada part and arm-eabi-gcc > > for the C part! > > > > Fix: delete the compiler_command line. > > Presumably, ... editing it to arm-eabi-gnatmake would also work? > > -- Brian Why not simply state the target using the (appropriately named) Target project attribute and then build using gprbuild? We use Target and Runtime attributes and it works like a charm: project xyz is for Languages use ("Ada"); for Target use "leon3-elf"; for Runtime ("Ada") use "ravenscar-full-leon3"; ... end XYZ; Are these two attributes not supported by FSF GNAT (yet)? We have moved our development from using gnatmake to gprbuild and we have never looked back. It simply works. Regards, MarkL ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-29 10:11 ` Mark Lorenzen @ 2015-06-29 11:17 ` Simon Wright 0 siblings, 0 replies; 14+ messages in thread From: Simon Wright @ 2015-06-29 11:17 UTC (permalink / raw) Mark Lorenzen <mark.lorenzen@gmail.com> writes: > Why not simply state the target using the (appropriately named) Target > project attribute and then build using gprbuild? We use Target and > Runtime attributes and it works like a charm: As I said to Brian, this was (intended to be!) a native build. > project xyz is > > for Languages use ("Ada"); > > for Target use "leon3-elf"; > for Runtime ("Ada") use "ravenscar-full-leon3"; > ... > > end XYZ; > > Are these two attributes not supported by FSF GNAT (yet)? Both of them are supported in GPRBUILD GPL 2015, but GPRBUILD GPL 2014 doesn't support Runtime. gnatmake doesn't do mixed-language builds, and won't support project files in the next release (of FSF GCC, I presume): $ gnatmake -v -P build warning: gnatmake -P is obsolete and will not be available in the next release; use gprbuild instead ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gprbuild fun 2015-06-29 9:58 ` Brian Drummond 2015-06-29 10:11 ` Mark Lorenzen @ 2015-06-29 11:10 ` Simon Wright 1 sibling, 0 replies; 14+ messages in thread From: Simon Wright @ 2015-06-29 11:10 UTC (permalink / raw) Brian Drummond <brian@shapes.demon.co.uk> writes: > On Sun, 28 Jun 2015 18:28:13 +0100, Simon Wright wrote: > >> I have a mixed-language GPR like >> >> project build is >> for languages use ("ada", "c"); >> for source_files use ("a.adb", "c.c"); >> package ide is >> for compiler_command ("ada") use "gnatmake"; >> end ide; >> end build; > >> and, if I have the native gcc and arm-eabi-gcc present in the PATH, >> gprbuild chooses to use the native gcc for the Ada part and arm-eabi-gcc >> for the C part! >> >> Fix: delete the compiler_command line. > > Presumably, ... editing it to arm-eabi-gnatmake would also work? But I wanted the native version! --target=x86_64-apple-darwin13. Which I've never had to say before. As you suggest, for compiler_command ("ada") use "arm-eabi-gnatmake" works, in the sense of selecting a consistent set of tools. But the thing is, if you specify compiler_command, gprconfig is invoked with e.g. gprconfig --batch -o /Users/simon/tmp/gprbuild-problem/auto.cgpr --target=all --config=c,, --config=ada,,,,gnatmake but if you don't it's invoked with gprconfig --batch -o /Users/simon/tmp/gprbuild-problem/auto.cgpr --target=x86_64-darwin --config=c,, --config=ada,, So where did it get --target=all from?! (and come to that where did x86_64-darwin come from? x86_64-apple-darwin I would have understood) ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-06-29 11:17 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-28 17:28 gprbuild fun Simon Wright 2015-06-28 18:09 ` Dmitry A. Kazakov 2015-06-28 19:22 ` David Botton 2015-06-28 21:37 ` vincent.diemunsch 2015-06-28 23:02 ` David Botton 2015-06-29 8:24 ` vincent.diemunsch 2015-06-29 8:36 ` Simon Wright 2015-06-29 8:57 ` Vincent 2015-06-29 8:29 ` Simon Wright 2015-06-28 20:08 ` Simon Wright 2015-06-29 9:58 ` Brian Drummond 2015-06-29 10:11 ` Mark Lorenzen 2015-06-29 11:17 ` Simon Wright 2015-06-29 11:10 ` Simon Wright
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox