* how to tell gnatmake to send executables to a different directory when compiling multi source? @ 2012-07-29 9:31 Nasser M. Abbasi 2012-07-29 10:00 ` Dmitry A. Kazakov ` (3 more replies) 0 siblings, 4 replies; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-29 9:31 UTC (permalink / raw) I have --+---src/main1.adb, main2.adb | +---obj/ | +---bin/ In src/ I have few Ada main programs. I can build all and tell gnatmake to send the *.o and *.ali to the obj/ directory using -D switch. But not able to find an option to tell it send the generated executable (main1.exe and main2.exe) to bin/ directory. Otherwise, it will put them in src/ For example, when in src/ directory, I type gnatmake -D ../obj *.adb But I can't write something like gnatmake -D ../obj -o../bin/ *.adb Since it is a multi-file gnatmake call: "gnatmake: cannot specify a single executable for several mains" (it is actually think ../bin/ above is a name of a 'file') If I want to use gnatmake from the command line, I would have to write gnatmake -D ../obj -o../bin/main1.exe main1.adb gnatmake -D ../obj -o../bin/main2.exe main2.adb I looked at all options here http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Switches-for-gnatmake.html#Switches-for-gnatmake May be I missed it. Any one knows a trick to do this? ps. I can do the above using a Makefile, using a rule, so I do not have to type the above gnatmake command for each file ofcourse, as Makefile will do it for me, using wildcard. I am just interested to see if it is possible using a switch, that is all. thanks --Nasser ps. I know gpr is supposed to be used for Ada, may be later when I learn, but for now, I am using gnatmake. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 9:31 how to tell gnatmake to send executables to a different directory when compiling multi source? Nasser M. Abbasi @ 2012-07-29 10:00 ` Dmitry A. Kazakov 2012-07-29 11:35 ` Nasser M. Abbasi 2012-07-29 18:33 ` how to tell gnatmake to send executables to a different directory when compiling multi source? björn lundin ` (2 subsequent siblings) 3 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2012-07-29 10:00 UTC (permalink / raw) On Sun, 29 Jul 2012 04:31:51 -0500, Nasser M. Abbasi wrote: > ps. I know gpr is supposed to be used for Ada, may be later when > I learn, but for now, I am using gnatmake. and you do: gnatmake -Pproject.gpr -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 10:00 ` Dmitry A. Kazakov @ 2012-07-29 11:35 ` Nasser M. Abbasi 2012-07-29 12:29 ` Patrick ` (3 more replies) 0 siblings, 4 replies; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-29 11:35 UTC (permalink / raw) On 7/29/2012 5:00 AM, Dmitry A. Kazakov wrote: > On Sun, 29 Jul 2012 04:31:51 -0500, Nasser M. Abbasi wrote: > >> ps. I know gpr is supposed to be used for Ada, may be later when >> I learn, but for now, I am using gnatmake. > > and you do: > > gnatmake -Pproject.gpr > Yes, I understand. And when I build a Java application, the Java programmers tell me to go use Ant build scripts as it is the best thing also for building Java applications. And GPR is the best thing to build Ada programs. And Python programmers use Paver to build their applications. And each group of programmers make their own tool to build their own language. It takes time to learn each tool. Well, I use Make. In the Makefile I can not only build Java, Ada, latex, my HTML pages, C, C++, Fortran, do my daily backup, and whatever else I want to automate using it. Make is not specialized to one task, but can do multiple tasks. It might not be the best for one specific task, but it is the best general tool for many many different things. For this particular case, it was pretty easy to solve this problem. I simply build everything in the directory, then after the build is done, just use bash command to move the images and the object files to different directories. --------------------------------------------- EXECUTABLE=lap1 lap21 lap22 lap23 lap31 lap41 lap42 all: ${EXECUTABLE} ${EXECUTABLE}: gnatmake $@.adb -largs -L/usr/lib -lblas -llapack -mv *.ali ../obj -mv *.o ../obj -mv $@ ../bin ----------------------------- --Nasser ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 11:35 ` Nasser M. Abbasi @ 2012-07-29 12:29 ` Patrick 2012-07-29 13:02 ` Nasser M. Abbasi 2012-07-29 12:31 ` Nasser M. Abbasi ` (2 subsequent siblings) 3 siblings, 1 reply; 65+ messages in thread From: Patrick @ 2012-07-29 12:29 UTC (permalink / raw) Cc: nma Hi Nasser I bet I know less then you do, so you might not want to follow me, I'm lost too :) I tried GPR and it's nice but I found it confusing once I starting mixing in C shared libraries. I just put all my files in different directories and use a shell script to cp them into a build directory. If I have 3 directories c, ada, mess. The shell script is this cp ./c/* ./mess; cp ./ada/* ./mess; cp Makefile ./mess ; cd ./mess ; make ; cd - ; cp ./mess/exec_file ./ ; ./exec_file ; I can't see a difference in build time on my machine with my small projects. HTH(and does not hurt instead!) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 12:29 ` Patrick @ 2012-07-29 13:02 ` Nasser M. Abbasi 2012-07-29 13:49 ` Ludovic Brenta 0 siblings, 1 reply; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-29 13:02 UTC (permalink / raw) On 7/29/2012 7:29 AM, Patrick wrote: > I just put all my files in different directories and use a shell >script to cp them into a build directory. > I do not think there is a need to do such things. use recursive make if you must. Make can run bash commands. Here is very simple note on using recusive Make http://12000.org/my_notes/cheat_sheets/make_notes/index.htm --Nasser ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 13:02 ` Nasser M. Abbasi @ 2012-07-29 13:49 ` Ludovic Brenta 2012-07-29 14:09 ` Nasser M. Abbasi 0 siblings, 1 reply; 65+ messages in thread From: Ludovic Brenta @ 2012-07-29 13:49 UTC (permalink / raw) Nasser M. Abbasi writes on comp.lang.ada: > On 7/29/2012 7:29 AM, Patrick wrote: > >> I just put all my files in different directories and use a shell >>script to cp them into a build directory. >> > > I do not think there is a need to do such things. use recursive make > if you must. > > Make can run bash commands. > > Here is very simple note on using recusive Make > > http://12000.org/my_notes/cheat_sheets/make_notes/index.htm And here is a very detailed note about why *not* to use recursive Make: http://miller.emu.id.au/pmiller/books/rmch/ -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 13:49 ` Ludovic Brenta @ 2012-07-29 14:09 ` Nasser M. Abbasi 2012-07-29 15:35 ` Ludovic Brenta 0 siblings, 1 reply; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-29 14:09 UTC (permalink / raw) On 7/29/2012 8:49 AM, Ludovic Brenta wrote: >> >> Here is very simple note on using recusive Make >> >> http://12000.org/my_notes/cheat_sheets/make_notes/index.htm > > And here is a very detailed note about why *not* to use recursive Make: > > http://miller.emu.id.au/pmiller/books/rmch/ > I know about this, and read it. It is a 'popular' link every time one says recursive make. All what it boils to, is that recursive make is not efficient. Ok. Big deal. I can wait 5 more seconds. I have an 8 quad PC and lots of ram :) I have been using recursive make for years, never seen a problem. So I do not need a 'paper' written 15 years ago to tell it is a bad idea. I run make from the top of my tree, go make coffee, check my mail, or take a short nap, and then it is done. It is really never been an issue for me. so why fix what is not broken :) But this is for my personal use. May be for a large company with millions of lines of code, then it is an issue. I do not know. There are always things one can do to improve anything they do I suppose. The problem is to pick the stuff that is most important to improve on. --Nasser ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 14:09 ` Nasser M. Abbasi @ 2012-07-29 15:35 ` Ludovic Brenta 2012-07-29 15:42 ` Patrick 2012-07-29 17:35 ` Vasiliy Molostov 0 siblings, 2 replies; 65+ messages in thread From: Ludovic Brenta @ 2012-07-29 15:35 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > On 7/29/2012 8:49 AM, Ludovic Brenta wrote: >>> Here is very simple note on using recusive Make >>> >>> http://12000.org/my_notes/cheat_sheets/make_notes/index.htm > >> And here is a very detailed note about why *not* to use recursive Make: >> >> http://miller.emu.id.au/pmiller/books/rmch/ > > I know about this, and read it. It is a 'popular' link every time one > says recursive make. > > All what it boils to, is that recursive make is not efficient. Ok. Big > deal. I can wait 5 more seconds. I have an 8 quad PC and lots of ram > :) No. The most important point is that recursive make defeats dependency management. This makes it virtually impossible to guarantee safe compilation, *especially* with languages other than Ada, which do not guarantee or enforce the consistency of source files with object files, or of object files with one another. > I have been using recursive make for years, never seen a problem. So I > do not need a 'paper' written 15 years ago to tell it is a bad idea. You have been hiding potential problems for years, then. No wonder you didn't see them. > I run make from the top of my tree, go make coffee, check my mail, or > take a short nap, and then it is done. It is really never been an > issue for me. so why fix what is not broken :) Running recursive make from the top of the tree is only half the solution. The full solution is to delete all files produced during the recursive make, then re-launch it again. This is a solution to a totally artificial problem (i.e. defeating dependency management) created by recursive make. And, of course, the solution of deleting all products of the compilation (object files, .ali files, executables, shared libraries, documentation, etc) *cannot* be implemented by recursive make, since recursive make creates the *problem*. > But this is for my personal use. May be for a large company with > millions of lines of code, then it is an issue. I do not know. There > are always things one can do to improve anything they do I > suppose. The problem is to pick the stuff that is most important to > improve on. Been there, done that. Believe me: recursive make is the devil. It is insidious and perverse; it creates problems and cunningly hides them from you. You don't even know they exist until they come and bite you. And of course, when they do you don't know where they come from. The irony is: just like the devil, you've created this mess yourself. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 15:35 ` Ludovic Brenta @ 2012-07-29 15:42 ` Patrick 2012-07-29 16:41 ` Ludovic Brenta 2012-07-29 17:35 ` Vasiliy Molostov 1 sibling, 1 reply; 65+ messages in thread From: Patrick @ 2012-07-29 15:42 UTC (permalink / raw) Hi Ludovic Is my super-ignorant shell script still a reasonably safe thing to do? Is there a name for this technique , surely I am not the only one using brute force and ignorance :) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 15:42 ` Patrick @ 2012-07-29 16:41 ` Ludovic Brenta 2012-07-29 16:46 ` Patrick 0 siblings, 1 reply; 65+ messages in thread From: Ludovic Brenta @ 2012-07-29 16:41 UTC (permalink / raw) Patrick writes: > Is my super-ignorant shell script still a reasonably safe thing to do? I wouldn't call it safe because of entropy: "duplicated information eventually becomes different information". Copying object files around creates the potential problem that you compile against up-to-date sources but link against obsolete object files. I personally prefer to use GNAT project files. They can tell gnatmake how to link Ada object files with a library produced separately. When I must also compile the library from source languages other than Ada, then I use a single-level Makefile (not recursive) that builds the non-Ada part(s) into a library (or several libraries) then calls gnatmake to build the Ada parts and link against the library. I make it so that copying object files is never necessary. One of the reasons I choose Ada as a programming language is because it helps me write clean, maintainable, solid software. Sometimes I must use Makefiles but that is no excuse for writing dirty, messy, fragile build systems, now is it? Therefore, like for all software, I try to make my Makefiles as simple as possible and as complex as necessary. My Makefiles are under version control like everything else, and I write them with the same care as everything else. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 16:41 ` Ludovic Brenta @ 2012-07-29 16:46 ` Patrick 0 siblings, 0 replies; 65+ messages in thread From: Patrick @ 2012-07-29 16:46 UTC (permalink / raw) okay, thanks again ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 15:35 ` Ludovic Brenta 2012-07-29 15:42 ` Patrick @ 2012-07-29 17:35 ` Vasiliy Molostov 2012-07-29 19:40 ` Dmitry A. Kazakov ` (2 more replies) 1 sibling, 3 replies; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-29 17:35 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Sun, 29 Jul 2012 19:35:51 +0400: > "Nasser M. Abbasi" <nma@12000.org> writes: >> On 7/29/2012 8:49 AM, Ludovic Brenta wrote: >>>> Here is very simple note on using recusive Make > Been there, done that. Believe me: recursive make is the devil. It is > insidious and perverse; it creates problems and cunningly hides them > from you. You don't even know they exist until they come and bite you. > And of course, when they do you don't know where they come from. The > irony is: just like the devil, you've created this mess yourself. Why people so warring against tools used by others? I wonder. It is well known that appropriate tool utilization can give appropriate result, and vise versa. Most open-source gnu c software are built using autotools with recursive make use, and it is ok. More productive is recursive and parallel make. And of course - handling "inter-goal" dependencies between subprojects in such recursive configuration is complex to describe in terms of makefile, but still possible. Perhaps, this is a personal devil, not collective. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 17:35 ` Vasiliy Molostov @ 2012-07-29 19:40 ` Dmitry A. Kazakov 2012-07-29 22:22 ` Vasiliy Molostov 2012-07-29 19:46 ` Robert A Duff 2012-07-30 6:06 ` Dirk Heinrichs 2 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2012-07-29 19:40 UTC (permalink / raw) On Sun, 29 Jul 2012 21:35:04 +0400, Vasiliy Molostov wrote: > Ludovic Brenta <ludovic@ludovic-brenta.org> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Sun, > 29 Jul 2012 19:35:51 +0400: > >> "Nasser M. Abbasi" <nma@12000.org> writes: >>> On 7/29/2012 8:49 AM, Ludovic Brenta wrote: >>>>> Here is very simple note on using recusive Make > >> Been there, done that. Believe me: recursive make is the devil. It is >> insidious and perverse; it creates problems and cunningly hides them >> from you. You don't even know they exist until they come and bite you. >> And of course, when they do you don't know where they come from. The >> irony is: just like the devil, you've created this mess yourself. > > Why people so warring against tools used by others? I wonder. There is a simple answer: Ludovic is one of Debian maintainers who knows the topic in-depth. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 19:40 ` Dmitry A. Kazakov @ 2012-07-29 22:22 ` Vasiliy Molostov 0 siblings, 0 replies; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-29 22:22 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Sun, 29 Jul 2012 23:40:40 +0400: > On Sun, 29 Jul 2012 21:35:04 +0400, Vasiliy Molostov wrote: > >> Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Sun, >> 29 Jul 2012 19:35:51 +0400: > There is a simple answer: Ludovic is one of Debian maintainers who knows > the topic in-depth. And perhaps as you know Ludovic then you know that he is formally in debian since 2006. I suppose if the problem with gnat ada sources against gnu makefiles is expressed incorrectly it seems that is not deep indeed. Also, Dmitry, I think that you are not in deep with that, so I wonder also and again why people prefer warring instead of thinking. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 17:35 ` Vasiliy Molostov 2012-07-29 19:40 ` Dmitry A. Kazakov @ 2012-07-29 19:46 ` Robert A Duff 2012-07-30 0:20 ` Vasiliy Molostov 2012-07-30 6:06 ` Dirk Heinrichs 2 siblings, 1 reply; 65+ messages in thread From: Robert A Duff @ 2012-07-29 19:46 UTC (permalink / raw) "Vasiliy Molostov" <molostoff@gmail.com> writes: > Ludovic Brenta <ludovic@ludovic-brenta.org> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Sun, >> Been there, done that. Believe me: recursive make is the devil. It is >> insidious and perverse; it creates problems and cunningly hides them >> from you. You don't even know they exist until they come and bite you. >> And of course, when they do you don't know where they come from. The >> irony is: just like the devil, you've created this mess yourself. > > Why people so warring against tools used by others? I wonder. Well, I don't see any need for "war" here. ;-) But anyway, I agree with Ludovic that recursive make causes a lot of trouble, and is best avoided. I can sympathize with the OP not wanting to learn about .gpr files for simple projects, but in that case, a simple 'make' file (non-recursive!) that invokes gnatmake can work well. If you can't figure out how to get gnatmake to put the executables where you want them, you can write some 'make' rules to copy them there. > It is well known that appropriate tool utilization can give appropriate > result, and vise versa. I'm not sure what you mean by "vice versa" in this case, but appropriate tool *choice* is also a good idea. Learning about .gpr files isn't trivial, but it won't kill you. And you might want to look at 'gprbuild', which can deal with multi-language projects -- .gpr is not just for Ada. > Most open-source gnu c software are built using autotools with recursive > make use, and it is ok. I disagree that it is OK. In my experience, recursive make leads to complications and inefficiencies. For small projects, the inefficiencies might not matter, but I once converted a large project from recursive make to non-recursive, and went from over-10-hour builds to under-1-hour builds in the from-scratch case, and even better speedups in the incremental re-build case. Even for small projects, the difference between "few seconds" and "go get a cup of coffee" involves forgetting one's train of thought. As for autotools, I think they are a nightmare, and totally unnecessary for a language like Ada. Gnat itself is built that way (because it's part of gcc), and it's nothing but trouble. > More productive is recursive and parallel make. How about parallel gnatmake, or parallel gprbuild? It's easy to write race conditions using parallel make, but parallel gnatmake/gprbuild doesn't have that problem. >...And of course - handling > "inter-goal" dependencies between subprojects > in such recursive configuration is complex to describe in terms of > makefile, but still possible. Hmm. I don't know any good way to deal with ``"inter-goal" dependencies between subprojects'' via recursive 'make'. Could you please outline your techniques? I don't much like 'make', but if I can learn some better 'make' techniques, that's a good thing, since I have to deal with it all the time! - Bob ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 19:46 ` Robert A Duff @ 2012-07-30 0:20 ` Vasiliy Molostov 2012-07-30 3:01 ` Nasser M. Abbasi ` (3 more replies) 0 siblings, 4 replies; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-30 0:20 UTC (permalink / raw) Robert A Duff <bobduff@shell01.theworld.com> писал(а) в своём письме Sun, 29 Jul 2012 23:46:11 +0400: > "Vasiliy Molostov" <molostoff@gmail.com> writes: > > Well, I don't see any need for "war" here. ;-) > But anyway, I agree with Ludovic that recursive make > causes a lot of trouble, and is best avoided. I think that the problem is not in "recursive", but in the fact that GNAT produces objects in other way than usual gnu/gcc tools do, I mean that not every input ada (gnat ada) source file refers to the corresponding output object file, and thus breaks makefile "predefined rules" approach used with C or other gcc related stuff, where each input source file type corresponds to its output file type. And this cause dependency inconsistency (in terms usual to makefile related tools), and one of the issues here is well expressed by Ludovic in his debian-ada policy against ALI files problem. But why the "recursive" is devil? Usual project contains many files that needs to be built, not only source code, but data, man pages and docs, configurations, all these are separate and usually built via recursive makefiles. Why to name a good time-proven tool as devil? I see no reason, only tendentious and imperatively expressed opinion. > I can sympathize with the OP not wanting to learn about .gpr files > for simple projects, but in that case, a simple 'make' file > (non-recursive!) that invokes gnatmake can work well. > If you can't figure out how to get gnatmake to put the executables > where you want them, you can write some 'make' rules to copy them there. > >> It is well known that appropriate tool utilization can give appropriate >> result, and vise versa. > > I'm not sure what you mean by "vice versa" in this case, but appropriate > tool *choice* is also a good idea. What I meant by vise versa: not well known tool utilization can give inappropriate result, and vise versa. > Learning about .gpr files isn't > trivial, but it won't kill you. And you might want to look at > 'gprbuild', which can deal with multi-language projects -- .gpr > is not just for Ada. How about recursive gprbuild? How about distributed gprbuild? >> Most open-source gnu c software are built using autotools with recursive >> make use, and it is ok. > > I disagree that it is OK. I doubt. I prefer makefiles in any kind, just because its widely used in unices, where most open-source software lives. Difficulty rises when someone comes with its own interface and tools, this makes things less compatible against environment. It is just an opinion, but I sure here is nothing devil or just anti-devil. > In my experience, recursive make leads to > complications and inefficiencies. For small projects, the > inefficiencies might not matter, but I once converted a large > project from recursive make to non-recursive, and went from > over-10-hour builds to under-1-hour builds in the from-scratch > case, and even better speedups in the incremental re-build case. How much time spending postgres sources build, what do you think? There are many recursive makefiles (at least up to 8.4) and I see no inefficiencies there. How about building it distributed across several hosts? > Even for small projects, the difference between "few seconds" and > "go get a cup of coffee" involves forgetting one's train > of thought. I doubt that makeing or building binaries can provide some possibility for thoughts about it. It is a final phase before 'make install'. > As for autotools, I think they are a nightmare, and totally unnecessary > for a language like Ada. Gnat itself is built that way (because it's > part of gcc), and it's nothing but trouble. No. very good, while used appropriately, especially for C related stuff. For Ada with gnat these are not appropriate enough of course, but it is not due to recursively calling make, or autotools by itself. They are just other tools for doing another things, and nothing else. Regarding autotools and ada, take a look at AWS source - I dont know why but you still need to 'configure' it. Would you like to know why? > Hmm. I don't know any good way to deal with ``"inter-goal" dependencies > between subprojects'' via recursive 'make'. Could you please outline > your techniques? I mean dependencies between subprojects (makefile "goals") defined for recursive make passes (directories with makefile, indeed), they become problematic when things depend on a subset of output files, not augmented in a component as a common standalone dependant unit and thus are not independent and atomic part of overall build process. This indeed can lead to an inconvenient problem of incomplete dependency "decomposition". But I suppose that this way make is used in unusual way as intermediate and temporary solution, so it can not be considered as devil. Just it can not handle all possible cases by itself, as every tool does - a hand and a head is required. > I don't much like 'make', but if I can learn some > better 'make' techniques, that's a good thing, since I have to deal > with it all the time! It is better to get some large (old-school) open source tar-ball (I have learned it via compiling suse distribution sources under solaris, including gnat gcc jgnat and the rest of 4+Gb raw source code) and at the same time to read gnu makefile reference manual - after two-three days of "sick" reading any well-motivated person can find himself well-grounded to do anything with makefiles. Also I think that debian is not good enough to learn usual "good" makefiles, since many debian package maintainers try to reach their package and subcomponent compatibility and do incorporating changes (patches and build instructions) that break build process defined by authors (this is a need, due to debian packaging and build bots environment, and is not a voluntary decision, but not always correct indeed). It is why better to get native tarball and all its dependencies, and it is why fsf gnat differs from debian gnat and from what we can get from libre.adacore. Why these last four do not use the same gprbuild project file everywhere? -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 0:20 ` Vasiliy Molostov @ 2012-07-30 3:01 ` Nasser M. Abbasi 2012-07-30 4:48 ` Nasser M. Abbasi ` (2 more replies) 2012-07-30 3:21 ` Nasser M. Abbasi ` (2 subsequent siblings) 3 siblings, 3 replies; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-30 3:01 UTC (permalink / raw) On 7/29/2012 7:20 PM, Vasiliy Molostov wrote: > > I doubt. I prefer makefiles in any kind, just because its widely used in > unices, where most open-source software lives. Difficulty rises when > someone comes with its own interface and tools, this makes things less > compatible against environment. It is just an opinion, but I sure here is > nothing devil or just anti-devil. > I had the same discussion in comp.lang.java sometime ago. Over there, everyone would scream at me for not using Ant to build Java projects, and I was using a Makefile. Here, people will scream at me for not using GPR for building Ada projects. I see Make as the lowest common denominator. Unless GPRBUILD can be used to build both Ada, Java, C, C++, etc.. and can be used also to invoke latex to update my pdf files and HTML web pages when my .tex files changes, and I can use it to do my backups and all the other tasks I use Make for, then I do not see something better as a general tool. Javac (the Java compiler) actually works like gnatnmake in many ways. i.e. doing javac -classpath ... *.java (can be done from inside Makefile) then javac knows which other files it needs to compile so that the build is consistent and complete. i.e. one does not need to tell it which java file depends on which other. Javac knows from the import statements and using the classpath it can determine which java files to build. Same with gnatmake, I can just write gnatmake -I ... *.adb from inside Makefile and that is all. It knows what files to compile as needed. Only problem was when it comes to sending the object files and the .exe to different places during the build. Ada is more complicated and has more intermediate files generated. If one does not mind keeping all files generated in the same folder as the sources, then the above is all what is needed for a basic Ada project build. --Nasser ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 3:01 ` Nasser M. Abbasi @ 2012-07-30 4:48 ` Nasser M. Abbasi 2012-07-30 21:05 ` Robert A Duff 2012-07-30 5:50 ` Dmitry A. Kazakov 2012-07-30 11:16 ` Vasiliy Molostov 2 siblings, 1 reply; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-30 4:48 UTC (permalink / raw) On 7/29/2012 10:01 PM, Nasser M. Abbasi wrote: > I can just write > > gnatmake -I ... *.adb > > from inside Makefile and that is all. It knows what files to compile > as needed. > For completion's sake, and for future generations :), I thought to show how I ended up doing a simple Makefile that uses gnatmake to build a project. Make is only used here as a 'wrapper' around gnatmake. gnatmake is the one doing the real work. Only reason to use Make is really just so that to avoid using bash scripts and to also allow recusrive make to work (so that I can write make from the top of the tree and have things build). Here is a simple example. Assume you have a folder with 2 main files (main1.adb and main2.adb) and want to build them, and they depend on other ada packages in another folder(s). Then put this Makefile in the folder with the main ada files -------------------------------------- EXECUTABLE=main1 main2 .PHONY: all all: ${EXECUTABLE} .PHONY: FORCE ${EXECUTABLE}: FORCE gnatmake -I../binding $@.adb -largs -L/usr/lib -lblas -llapack FORCE: clean: -rm ${EXECUTABLE} -rm *.ali -rm *.o ---------------------------- The FORCE trick above forces Make to invoke gnatmake each time. That is OK, since gnatmake then decided if it needs to actually compile things or not. In the above example, `-I` just points to other folders that have Ada sources that have packages with'ed by these files. (this is all normal gnatmake stuff here). So, all what one needs to do is make In the above, all output (exeutables and ali files and .o files are generated in the same folder). make clean will clean everything. Now one can add more target to the Makefile to do other things, like run a specific test, etc... i.e. Normal Makefile things. --Nasser ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 4:48 ` Nasser M. Abbasi @ 2012-07-30 21:05 ` Robert A Duff 0 siblings, 0 replies; 65+ messages in thread From: Robert A Duff @ 2012-07-30 21:05 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > Make is only used here as a 'wrapper' around gnatmake. gnatmake is > the one doing the real work. Only reason to use Make is really just > so that to avoid using bash scripts and to also allow recusrive make > to work (so that I can write make from the top of the tree and > have things build). The make file you show below looks perfectly reasonable to me. It's simple, and is not recursive. If you don't want to waste time learning gnatmake/gprbuild/project files, and you don't need that functionality, this is a reasonable approach. But I don't understand your reference to "recursive make" above. You don't need recursive make in order to do "make" from the top of the tree and build everything. If your Ada files are scattered all over a bunch of subdirectories, you can just mention those directories with the -I switch. If you have C files mixed in, that doesn't change things -- you still don't need recursive make. This make file doesn't put the executables where you wanted them, but it's not hard to write some rules that will copy or move them, or create links. But I advise you to not let your make files get complicated, and try to avoid recursive make. The paper somebody mentioned explains why recursive make causes trouble, and why you don't need it. > Here is a simple example. Assume you have a folder with 2 main files > (main1.adb and main2.adb) and want to build them, and they depend on > other ada packages in another folder(s). > > Then put this Makefile in the folder with the main ada files > > -------------------------------------- > EXECUTABLE=main1 main2 > > .PHONY: all > all: ${EXECUTABLE} > > .PHONY: FORCE > > ${EXECUTABLE}: FORCE > gnatmake -I../binding $@.adb -largs -L/usr/lib -lblas -llapack > > FORCE: > > clean: > -rm ${EXECUTABLE} > -rm *.ali > -rm *.o > ---------------------------- - Bob ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 3:01 ` Nasser M. Abbasi 2012-07-30 4:48 ` Nasser M. Abbasi @ 2012-07-30 5:50 ` Dmitry A. Kazakov 2012-07-30 11:16 ` Vasiliy Molostov 2 siblings, 0 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2012-07-30 5:50 UTC (permalink / raw) On Sun, 29 Jul 2012 22:01:11 -0500, Nasser M. Abbasi wrote: > Here, people will scream at me for not using GPR for building > Ada projects. Not only Ada projects. If you want to spare -largs stuff in gnatmake, be able to link against static or dynamic version, you describe the external library (e.g. liblapack.a, liblapack.so, lapack.lib etc) like: project lapack is for Externally_Built use "true"; for Source_Files use (); for Library_Dir use "/usr/lib/x86_64-linux_gnu"; for Library_Name use "lapack"; type Library_Kind_Type is ("static", "relocatable"); Library_Kind : Library_Kind_Type := external ("Library_Type", "relocatable"); for Library_Kind use Library_Kind; end lapack; The project containing the bindings will simply "with" the library projects blas, lapack etc. GNAT knows naming conventions of the given host and figures out proper linker options for each scenario. It is a very useful feature when you have lots of external libraries. Something like GTK may require dozens of libraries. When you have multiple targets you change the library project files and leave the binding project file and any other project files intact. > I see Make as the lowest common denominator. Already tried your stuff with nmake? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 3:01 ` Nasser M. Abbasi 2012-07-30 4:48 ` Nasser M. Abbasi 2012-07-30 5:50 ` Dmitry A. Kazakov @ 2012-07-30 11:16 ` Vasiliy Molostov 2012-07-30 12:25 ` Georg Bauhaus 2 siblings, 1 reply; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-30 11:16 UTC (permalink / raw) Nasser M. Abbasi <nma@12000.org> писал(а) в своём письме Mon, 30 Jul 2012 07:01:11 +0400: > On 7/29/2012 7:20 PM, Vasiliy Molostov wrote: > > I see Make as the lowest common denominator. Unless GPRBUILD can > be used to build both Ada, Java, C, C++, etc.. and can be used also > to invoke latex to update my pdf files and HTML web pages when my > .tex files changes, and I can use it to do my backups and all > the other tasks I use Make for, then I do not see something better > as a general tool. Agree. A general tool is more useful than specialized one, of course. > Only problem was when it comes to sending the object files > and the .exe to different places during the build. Ada is more > complicated and has more intermediate files generated. If one > does not mind keeping all files generated in the same folder as > the sources, then the above is all what is needed for a basic > Ada project build. So the problem here is how GNAt generates its output, and it is not related to make by itself, and can not turn other things into a devil. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 11:16 ` Vasiliy Molostov @ 2012-07-30 12:25 ` Georg Bauhaus 2012-07-30 12:59 ` Vasiliy Molostov 2012-07-30 13:03 ` Nasser M. Abbasi 0 siblings, 2 replies; 65+ messages in thread From: Georg Bauhaus @ 2012-07-30 12:25 UTC (permalink / raw) On 30.07.12 13:16, Vasiliy Molostov wrote: > Nasser M. Abbasi <nma@12000.org> писал(а) в своём письме Mon, 30 Jul 2012 > 07:01:11 +0400: > >> On 7/29/2012 7:20 PM, Vasiliy Molostov wrote: >> > >> I see Make as the lowest common denominator. Unless GPRBUILD can >> be used to build both Ada, Java, C, C++, etc.. and can be used also >> to invoke latex to update my pdf files and HTML web pages when my >> .tex files changes, and I can use it to do my backups and all >> the other tasks I use Make for, then I do not see something better >> as a general tool. > > Agree. A general tool is more useful than specialized one, of course. > >> Only problem was when it comes to sending the object files >> and the .exe to different places during the build. Ada is more >> complicated and has more intermediate files generated. If one >> does not mind keeping all files generated in the same folder as >> the sources, then the above is all what is needed for a basic >> Ada project build. > > So the problem here is how GNAt generates its output, and it is not > related to make by itself, and can not turn other things into a devil. You mean, compilation processes, in phases, number of intermediate files, etc., should be kept simple and few, so that proud Make loving people can continue doing what they seem to be doing? I do use Make for auxiliary tasks. For starting tests runs. For packaging. For transforming documentation. So don't get me wrong. I like Make. And indeed, Ada won't turn anything into anything else when that already is. But it will expose a state of things with C files and Make. That's the point: it lets you see things. If a language defines "elaboration", if it states what it means for one unit to depend on another, in source, and if a language requires that compilers address the issue, then this language create processes of production that are necessarily different from what you get with C. IMHO, the difference between Ada and C here shows a big blind spot in the C world, one that can create cost of development and frustrated programmers (porting software): a tool that is not covered by the C standard. The blind spot has two aspects, and, correspondingly, there are two ways of ignoring the blind spot, blissfully, even after learning about it: 1) [socially] Since frustration and cost of preparing C source files for compilation are ubiquitous, it is taken as normal. It will take something like the Ada experience to make them appear as *not* normal if seen across language definitions. But this new insight won't matter since everybody writes Makefiles (And, for that matter, uses auto****, another non-C thing that could not exist but for hysteric raisins). 2) [individually] C is a can-do-it language, top to almost bottom. (Ada is more of a has-it language.) Therefore, can-do-it people writing C will secure an opportunity of being proud of having managed dependencies themselves (I-can-do-it). So, for any one given point in time, they have managed the dependencies for the current set of C sources. Great! Taken together, naturally, adding a working set of definitions relating to dependence to C is fenced off, not only on the ground that this reduces flexibility in individual cases, but also becuase this addition would seem to take away your favorite toys. The Ada experience lets you see the devil in the details, when it comes to all those changes. Bob Duff gave an example (of compilation time being a tenth or less). Changes in the C world require programmers who know both C and the dependency graph of the entire software. Hence, this creates more opportunities for more integration tests, all unneccessary to the extent that your language defines dependence. 3) [economically] C is a good language for a business model focussing on a certain class of tools dealing with dependence of C source files, such as Make. Use the blind spot for gain. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 12:25 ` Georg Bauhaus @ 2012-07-30 12:59 ` Vasiliy Molostov 2012-07-30 14:07 ` Georg Bauhaus 2012-07-30 13:03 ` Nasser M. Abbasi 1 sibling, 1 reply; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-30 12:59 UTC (permalink / raw) Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Mon, 30 Jul 2012 16:25:20 +0400: > You mean, compilation processes, in phases, number of intermediate > files, etc., should be kept simple and few, so that proud Make > loving people can continue doing what they seem to be doing? Perhaps I mean that interfacing and incorporating ada related projects with other stuff, like AWs and tls/ssl. > The Ada experience lets you see the devil in the details, when > it comes to all those changes. Bob Duff gave an example (of > compilation time being a tenth or less). Changes in the C world > require programmers who know both C and the dependency graph of > the entire software. Hence, this creates more opportunities for > more integration tests, all unneccessary to the extent that your > language defines dependence. yep, and the resulting conclusion is that Ada is better here. But better and faster car can not make neighbour's car devil or incorrect. It is weak logic to accept that having better tool turns other tools (not yours) to a devil thing. Similar to wearing a different hat you can not make others worse or better than they are. > 3) [economically] C is a good language for a business model > focussing on a certain class of tools dealing with dependence > of C source files, such as Make. Use the blind spot for gain. Any bussiness is aimed to the profit (fast profit), so the answer here is that the entry cost for C development is much less than for Ada. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 12:59 ` Vasiliy Molostov @ 2012-07-30 14:07 ` Georg Bauhaus 0 siblings, 0 replies; 65+ messages in thread From: Georg Bauhaus @ 2012-07-30 14:07 UTC (permalink / raw) On 30.07.12 14:59, Vasiliy Molostov wrote: > But better and faster car can not make neighbour's car devil or incorrect. > It is weak logic to accept that having better tool turns other tools (not > yours) to a devil thing. A non-devilish car (Ada compilation process) won't make the neighbor's car (C + recursive make + autoconf + Unix) the devil. But if it already is---like so many, the crappy things bumping into others, driving over poor animals surprised by the cars' squiggly motions, etc---then your exemplar of a well behaved vehicle might make others see what those neighbors' cars really are. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 12:25 ` Georg Bauhaus 2012-07-30 12:59 ` Vasiliy Molostov @ 2012-07-30 13:03 ` Nasser M. Abbasi 2012-07-30 14:02 ` Georg Bauhaus ` (2 more replies) 1 sibling, 3 replies; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-30 13:03 UTC (permalink / raw) On 7/30/2012 7:25 AM, Georg Bauhaus wrote: > . Changes in the C world > require programmers who know both C and the dependency graph of > the entire software. hi; I do not know if this is what you refer to or not, but gcc can generate, _automatically_, a dependency file (.d extension) using the gcc -M flag. Then this .d file is included into the Makefile, in the fly, and hence used by Make to know the current dependency. So, this step is automated, and programmers do not need to know the dependency graph of the entire software really. Here is a link that describes this and more , called "Advanced Auto-Dependency Generation" http://make.paulandlesley.org/autodep.html The point is, there are ways to build this dependency automatically in the C world. (ofcurse, the Ada way, with gnatmake is so much simpler and easier, since this is all part of the language itself and not part of the build 'tools', but if one is using C and C++ then there ways to do this). --Nasser ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 13:03 ` Nasser M. Abbasi @ 2012-07-30 14:02 ` Georg Bauhaus 2012-07-30 19:40 ` J-P. Rosen 2012-07-30 19:50 ` Ludovic Brenta 2 siblings, 0 replies; 65+ messages in thread From: Georg Bauhaus @ 2012-07-30 14:02 UTC (permalink / raw) On 30.07.12 15:03, Nasser M. Abbasi wrote: > On 7/30/2012 7:25 AM, Georg Bauhaus wrote: > > >> . Changes in the C world >> require programmers who know both C and the dependency graph of >> the entire software. > > hi; > > I do not know if this is what you refer to or not, (...) > http://make.paulandlesley.org/autodep.html > > The point is, there are ways to build this dependency automatically > in the C world. The author seems a little cautious. The point is that C does not define a library unit and how it fits into the translation process, dependency-wise, like Ada does. There are economical consequences. C's, uh, permissive ways create a plethora of mutually incompatible solutions to a problem that has been formally defined, and solved, in Ada right from the start. So, there exist cases where GCC, with the help of GNU Make and a host of Unix programs, will let a diligent programmer produce dependency files that tackle dependency in a roll-your-own fashion. This setup is all outside of C, non-portable, "pragmatic", and works, provided a sufficient amount of crowd work and crowd money are spent on additions to C programming that tend become mutually exclusive. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 13:03 ` Nasser M. Abbasi 2012-07-30 14:02 ` Georg Bauhaus @ 2012-07-30 19:40 ` J-P. Rosen 2012-08-01 7:32 ` Miles Bader 2012-07-30 19:50 ` Ludovic Brenta 2 siblings, 1 reply; 65+ messages in thread From: J-P. Rosen @ 2012-07-30 19:40 UTC (permalink / raw) Le 30/07/2012 15:03, Nasser M. Abbasi a écrit : > I do not know if this is what you refer to or not, but gcc can generate, > _automatically_, a dependency file (.d extension) using the gcc -M flag. (Disclaimer: I didn't know about that option). However, I assume that this works only if the programmer properly used the appropriate .h files, which is in no way required by C. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 19:40 ` J-P. Rosen @ 2012-08-01 7:32 ` Miles Bader 2012-08-01 9:37 ` Ludovic Brenta 2012-08-01 15:15 ` J-P. Rosen 0 siblings, 2 replies; 65+ messages in thread From: Miles Bader @ 2012-08-01 7:32 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> writes: >> I do not know if this is what you refer to or not, but gcc can generate, >> _automatically_, a dependency file (.d extension) using the gcc -M flag. > (Disclaimer: I didn't know about that option). > > However, I assume that this works only if the programmer properly used > the appropriate .h files, which is in no way required by C. It assumes nothing about the way .h files are used. It essentially emits the include-file graph in an appropriate format, usable by make. -miles -- I'd rather be consing. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-08-01 7:32 ` Miles Bader @ 2012-08-01 9:37 ` Ludovic Brenta 2012-08-02 5:01 ` Miles Bader 2012-08-01 15:15 ` J-P. Rosen 1 sibling, 1 reply; 65+ messages in thread From: Ludovic Brenta @ 2012-08-01 9:37 UTC (permalink / raw) Miles Bader wrote: > "J-P. Rosen" writes: >>> I do not know if this is what you refer to or not, but gcc can generate, >>> _automatically_, a dependency file (.d extension) using the gcc -M flag. >> (Disclaimer: I didn't know about that option). > >> However, I assume that this works only if the programmer properly used >> the appropriate .h files, which is in no way required by C. > > It assumes nothing about the way .h files are used. > > It essentially emits the include-file graph in an appropriate format, > usable by make. In fact it does assume something. The assumption is, as is usual in the C world, hidden, so you don't see it. The hidden assumption here is that the -I flags and environment variables passed to the compiler to find the include files are the same when extracting the dependencies with -M and later when compiling using the extracted dependencies. Breaking this assumption breaks the build in ways impossible to predict and almost impossible to debug. It takes a proper software engineer to detect hidden assumptions. Jean-Pierre is one. Hidden assumptions are *also* the devil. -- Ludovic Brenta. The plannings leverage a forward planning. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-08-01 9:37 ` Ludovic Brenta @ 2012-08-02 5:01 ` Miles Bader 0 siblings, 0 replies; 65+ messages in thread From: Miles Bader @ 2012-08-02 5:01 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > Miles Bader wrote: >>> However, I assume that this works only if the programmer properly used >>> the appropriate .h files, which is in no way required by C. >> >> It assumes nothing about the way .h files are used. >> >> It essentially emits the include-file graph in an appropriate format, >> usable by make. > > The hidden assumption here is that the -I flags and environment > variables passed to the compiler to find the include files are the > same when extracting the dependencies with -M and later when compiling > using the extracted dependencies. Sure, but that's not "the way .h files are used." These days the compiler is usually only invoked once, using -M as an additional option during the "real compile," which avoids the issue of inconsistent invocation. Each compile then essentially makes sure the recorded dependency information is consistent with the object files. [It's still of course possible to confuse things, e.g., by changing a "-DFOO" option when FOO affects the include-graph, so some build systems record the actual compiler options, and do a full recompile whenever they change...] Note that I'm not trying to say this is an elegant system -- it has many obvious problems, and I think the "Ada way" is clearly better -- just that in practice, it often more or less, kinda-sorta, works. It's well understood how clumsy all this is, and in the long run C++ will probably move more towards doing things like Ada does. My perception is that a real module system (supplanting include files) is high on many people's agenda for the next C++ standard. -miles -- I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-08-01 7:32 ` Miles Bader 2012-08-01 9:37 ` Ludovic Brenta @ 2012-08-01 15:15 ` J-P. Rosen 2012-08-02 15:08 ` Robert A Duff 1 sibling, 1 reply; 65+ messages in thread From: J-P. Rosen @ 2012-08-01 15:15 UTC (permalink / raw) Le 01/08/2012 09:32, Miles Bader a �crit : > It assumes nothing about the way .h files are used. > > It essentially emits the include-file graph in an appropriate format, > usable by make. > Well, apparently it assumes that #include is used for every needed library - and nothing /requires/ that in the C standard. An undisciplined programmer could copy lines instead of #including them, and then all tools will be fooled. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-08-01 15:15 ` J-P. Rosen @ 2012-08-02 15:08 ` Robert A Duff 2012-08-02 16:37 ` J-P. Rosen 0 siblings, 1 reply; 65+ messages in thread From: Robert A Duff @ 2012-08-02 15:08 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> writes: > Well, apparently it assumes that #include is used for every needed > library - and nothing /requires/ that in the C standard. An > undisciplined programmer could copy lines instead of #including them, > and then all tools will be fooled. I don't think that's a very strong criticism of C. Yeah, you're right that it's not required to use #include properly, but every competent C programmer does so. It's not like you can do it wrong by accident. Compare to (say) array indexing, where it's easy to accidentally go out of bounds. Of course I agree that a language with a proper module system is better. Patient: "Doctor, it hurts when I copy lines instead of #including them." Doctor: "So don't do that." - Bob ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-08-02 15:08 ` Robert A Duff @ 2012-08-02 16:37 ` J-P. Rosen 0 siblings, 0 replies; 65+ messages in thread From: J-P. Rosen @ 2012-08-02 16:37 UTC (permalink / raw) Le 02/08/2012 17:08, Robert A Duff a �crit : > "J-P. Rosen" <rosen@adalog.fr> writes: > >> Well, apparently it assumes that #include is used for every needed >> library - and nothing /requires/ that in the C standard. An >> undisciplined programmer could copy lines instead of #including them, >> and then all tools will be fooled. > > I don't think that's a very strong criticism of C. Yeah, you're right > that it's not required to use #include properly, but every competent > C programmer does so. It's not like you can do it wrong by accident. > Compare to (say) array indexing, where it's easy to accidentally > go out of bounds. > > Of course I agree that a language with a proper module system is better. > > Patient: "Doctor, it hurts when I copy lines instead of #including them." > Doctor: "So don't do that." > Sure. As long as you are not in the safety critical area. Tell the certifier "nobody does that", and the certifier will respond: "prove it". -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 13:03 ` Nasser M. Abbasi 2012-07-30 14:02 ` Georg Bauhaus 2012-07-30 19:40 ` J-P. Rosen @ 2012-07-30 19:50 ` Ludovic Brenta 2 siblings, 0 replies; 65+ messages in thread From: Ludovic Brenta @ 2012-07-30 19:50 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > Here is a link that describes this and more , called > "Advanced Auto-Dependency Generation" > > http://make.paulandlesley.org/autodep.html I like this title very much; it reflects very well the poor state of the art in C (and C++) programming. - they think they "generate" dependencies by parsing source files. This is wrong. They generate dependencies when _writing_ the source files. GCC has a tool to _extract_ not _generate_ dependencies. - they think this technology is "advanced". This is wrong. Ada has had automatic dependency management mandated in the language since 1979. Other languages like OCaml too. - by "advanced" they imply that "this is not for beginners or the faint of heart". Taking advantage of this "advanced" technology requires mastery of C, GCC and Make. Not to mention the vendor lock-in that results from relying on a non-standard feature of GCC. On the contrary, beginners are the ones who need help the most, even those not using GCC or Make. - they are proud to have "invented" an "advanced technology", just like Georg described. While they "can do it", Ada already "has it". They simply don't have a clue, do they? Well, I contend that they are being seduced and blinded by their own devil. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 0:20 ` Vasiliy Molostov 2012-07-30 3:01 ` Nasser M. Abbasi @ 2012-07-30 3:21 ` Nasser M. Abbasi 2012-07-30 8:19 ` Simon Wright 2012-07-30 6:12 ` Dirk Heinrichs 2012-07-30 6:40 ` Ludovic Brenta 3 siblings, 1 reply; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-30 3:21 UTC (permalink / raw) On 7/29/2012 7:20 PM, Vasiliy Molostov wrote: > > It is better to get some large (old-school) open source tar-ball (I have > learned it via compiling suse distribution sources under solaris, > including gnat gcc jgnat and the rest of 4+Gb raw source code) and at the > same time to read gnu makefile reference manual - after two-three days of > "sick" reading any well-motivated person can find himself well-grounded to > do anything with makefiles. > I learned Make many years ago when I had to build Netscape web server on another flavor of Unix. The web server was about 1 or 2 million lines of C code (not sure, but it was big) with tons of those lovely #ifdefs, and the makefiles would build this source code for 16 or so different platforms. Yes, that many different flavors of Unix including windows and OS/2 also (many of these flavors of Unix are dead now. The Netscape web server itself is not around any more ofcourse, this was in back in the days of Netscape glory). But I remember spending weeks just doing nothing but trying to figure out how the Makefiles work in order to make the need adjustment to add the platform I wanted to build the sources for. --Nasser ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 3:21 ` Nasser M. Abbasi @ 2012-07-30 8:19 ` Simon Wright 0 siblings, 0 replies; 65+ messages in thread From: Simon Wright @ 2012-07-30 8:19 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > But I remember spending weeks just doing nothing but trying to figure > out how the Makefiles work in order to make the need adjustment to add > the platform I wanted to build the sources for. I think the answer is imake. (only quarter-serious. Back in the day imake served me well on a multi-component project buildable for Linux, OSF/1, Solaris). ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 0:20 ` Vasiliy Molostov 2012-07-30 3:01 ` Nasser M. Abbasi 2012-07-30 3:21 ` Nasser M. Abbasi @ 2012-07-30 6:12 ` Dirk Heinrichs 2012-07-30 6:40 ` Ludovic Brenta 3 siblings, 0 replies; 65+ messages in thread From: Dirk Heinrichs @ 2012-07-30 6:12 UTC (permalink / raw) Vasiliy Molostov wrote: > But why the "recursive" is devil? Usual project contains many files that > needs to be built, not only source code, but data, man pages and docs, > configurations, all these are separate and usually built via recursive > makefiles. Why to name a good time-proven tool as devil? I see no reason, > only tendentious and imperatively expressed opinion. No, it's not opinion. I've seen enough recursive build systems to know that Miller's paper is correct. One cannot do reliable iterative builds (especially not parallel ones) with a recursive build system. One always have to "make clean" and build from scratch to get reliable results. What a waste of time. Bye... Dirk -- Dirk Heinrichs <dirk.heinrichs@altum.de> Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 0:20 ` Vasiliy Molostov ` (2 preceding siblings ...) 2012-07-30 6:12 ` Dirk Heinrichs @ 2012-07-30 6:40 ` Ludovic Brenta 2012-07-30 10:31 ` Vasiliy Molostov 3 siblings, 1 reply; 65+ messages in thread From: Ludovic Brenta @ 2012-07-30 6:40 UTC (permalink / raw) "Vasiliy Molostov" <molostoff@gmail.com> writes: > Robert A Duff <bobduff@shell01.theworld.com> писал(а) в своём письме > Sun, 29 Jul 2012 23:46:11 +0400: > >> "Vasiliy Molostov" <molostoff@gmail.com> writes: >> >> Well, I don't see any need for "war" here. ;-) >> But anyway, I agree with Ludovic that recursive make >> causes a lot of trouble, and is best avoided. > > I think that the problem is not in "recursive", but in the fact that > GNAT produces objects in other way than usual gnu/gcc tools do, I mean > that not every input ada (gnat ada) source file refers to the > corresponding output object file, and thus breaks makefile > "predefined rules" approach used with C or other gcc related stuff, > where each input source file type corresponds to its output file > type. And this cause dependency inconsistency (in terms usual to > makefile related tools), and one of the issues here is well expressed > by Ludovic in his debian-ada policy against ALI files problem. No, even in C an object file corresponds to not one but *several* input files: one or possibly several *.c and many *.h files. Make was invented to compensate for the deficiencies of C, which does not track dependencies, and Make does a bad job of that, even in simple projects. > But why the "recursive" is devil? Usual project contains many files > that needs to be built, not only source code, but data, man pages and > docs, configurations, all these are separate and usually built via > recursive makefiles. Just because many lemmings are wrong doesn't make them right. Read the paper; it explains very well how recursive makefiles defeat dependency management completely. This is the cause for the biggest and most insidious problems. > Why to name a good time-proven tool as devil? I see no reason, only > tendentious and imperatively expressed opinion. Make and especially recursive make have been time-proven to be fragile, unmaintainable, error-prone and inefficient. > What I meant by vise versa: not well known tool utilization can give > inappropriate result, and vise versa. You are correct here. Using make recursively is *bad* use of make, only made by people who don't know make. And the results are, of course, inappropriate. > How about recursive gprbuild? How about distributed gprbuild? That doesn't exist. gprbuild doesn't call itself recursively. Instead, gnatmake and gprbuild read the entire closure of project files (within each other, including each other, extending each other) and processes this entire closure non-recursively. It is possible and recommended to use make the same way, i.e. by means of include Makefiles instead of recursive. > I doubt. I prefer makefiles in any kind, just because its widely used > in unices, where most open-source software lives. Difficulty rises > when someone comes with its own interface and tools, this makes things > less compatible against environment. It is just an opinion, but I sure > here is nothing devil or just anti-devil. This is a valid point. The problem is that Make doesn't know about dependencies between Ada units like gnatmake does; therefore Make violates the Ada Reference manual. In short, when compiling Ada you *must* use gnatmake or its equivalent for another compiler than GNAT. And yo *must* use whatever configuration file is appropriate for gnatmake. [about autotools] > No. very good, while used appropriately, especially for C related > stuff. Make was invented to compensate for the deficiencies of C with respect to dependency managament. Automake was invented to compensate for the deficiencies of Make with respect to maintenance of fragile and huge Makefiles (i.e. the inappropriate use of Make). Autoconf was invented to compensate for the deficiencies of Automake with respect to configuration management and of C with respect to portability, even across Unices. Ada has none of these deficiencies. > For Ada with gnat these are not appropriate enough of course, but it > is not due to recursively calling make, or autotools by itself. They > are just other tools for doing another things, and nothing > else. Regarding autotools and ada, take a look at AWS source - I dont > know why but you still need to 'configure' it. Would you like to know > why? I know why. The configure in AWS is not constructed with autoconf, it is written by hand and is minimalistic. The things that need configuring are: whether or not to support SSL or GNU TLS, etc. i.e. which libraries other than AWS are present on the system and should be used. And AWS does not use automake either. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 6:40 ` Ludovic Brenta @ 2012-07-30 10:31 ` Vasiliy Molostov 2012-07-30 11:05 ` Ludovic Brenta 0 siblings, 1 reply; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-30 10:31 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Mon, 30 Jul 2012 10:40:28 +0400: > No, even in C an object file corresponds to not one but *several* input > files: one or possibly several *.c and many *.h files. Make was > invented to compensate for the deficiencies of C, which does not track > dependencies, and Make does a bad job of that, even in simple projects. As we can see from predefined make rules %.o: %.c which means that C input source file has a direct correspondence to a resulting object file, and which is not applicable to gnat ada sources at all. Make is a general tool supporting that strict input-output pairing correspondence approach. As for dependencies of C code and header files (*.h) they are come from gcc autogenerated dependencies, lately included into makefile as a part. And indeed it is a helper, since a hand intervention is still might be required to express an author wish. The way it works is similar to all C stuff, someone has even named it as dancing with a blade. Is it danger? Perhaps. Is it devil? >> But why the "recursive" is devil? Usual project contains many files >> that needs to be built, not only source code, but data, man pages and >> docs, configurations, all these are separate and usually built via >> recursive makefiles. > > Just because many lemmings are wrong doesn't make them right. Read the > paper; it explains very well how recursive makefiles defeat dependency > management completely. This is the cause for the biggest and most > insidious problems. I have read them in a count that is inappropriate for the moment, many papers expressing novice opinion about danger of any thing, similar to warnings about smoking and fugu fish eating. None of them are good, because make (fish, smoke) still exist and widely used and happily consumed. And used mush more widely than Ada or Java. If someone fills that people in danger with that tool, please be so kind to correct existing or to write a better tool, which is the right way, but as for me I am sick and tired from advices about devil things (like ada.calendar.time), those came from personal desire, and produce only warring about a need (a requirement!) of restrictive use, without constructive movement forward. >> Why to name a good time-proven tool as devil? I see no reason, only >> tendentious and imperatively expressed opinion. > > Make and especially recursive make have been time-proven to be fragile, > unmaintainable, error-prone and inefficient. Do you plan to rewrite all these old good debian packages? > It is possible and recommended to > use make the same way, i.e. by means of include Makefiles instead of > recursive. You can suppose here that make can include not complete makefiles but dependency info collected by a separate tool. > This is a valid point. The problem is that Make doesn't know about > dependencies between Ada units like gnatmake does; therefore Make > violates the Ada Reference manual. In short, when compiling Ada you > *must* use gnatmake or its equivalent for another compiler than GNAT. > And yo *must* use whatever configuration file is appropriate for > gnatmake. *must* should better sounds with *can*, since this approach relates to GNAT only. And as a consequence the GNAT compilation model approach can not turn makefile into a devil thing. This is the same as personal haircut can not turn outer world into an ambiguous state. > Ada has none of these deficiencies. > >> For Ada with gnat these are not appropriate enough of course, but it >> is not due to recursively calling make, or autotools by itself. They >> are just other tools for doing another things, and nothing >> else. Regarding autotools and ada, take a look at AWS source - I dont >> know why but you still need to 'configure' it. Would you like to know >> why? > > I know why. The configure in AWS is not constructed with autoconf, it > is written by hand and is minimalistic. The things that need > configuring are: whether or not to support SSL or GNU TLS, > etc. i.e. which libraries other than AWS are present on the system and > should be used. And AWS does not use automake either. So here we can see when "none of these deficiencies" becomes a need to establish environment capabilities in "tls/ssl and etc" dependencies. So the correct answer here is that GNAT Ada has some deficiencies but in general they are different from C approach. And no devil, indeed. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 10:31 ` Vasiliy Molostov @ 2012-07-30 11:05 ` Ludovic Brenta 2012-07-30 11:33 ` Simon Wright 2012-07-30 12:16 ` Vasiliy Molostov 0 siblings, 2 replies; 65+ messages in thread From: Ludovic Brenta @ 2012-07-30 11:05 UTC (permalink / raw) Vasiliy Molostov wrote on comp.lang.ada: > Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Mon, > As we can see from predefined make rules > > %.o: %.c > > which means that C input source file has a direct correspondence to a > resulting object file, and which is not applicable to gnat ada sources at > all. Make is a general tool supporting that strict input-output pairing > correspondence approach. > > As for dependencies of C code and header files (*.h) they are come from > gcc autogenerated dependencies, lately included into makefile as a part. Don't you see how wrong this approach is? - The Makefile must call gcc -M to generate the dependencies and store them in a file - The Makefile *cannot* include the generated dependency file while it runs - therefore you must run make twice: (1) to generate the dependency info and (2) to build using the dependency info. Add to that that Make dependencies do not take compiler flags into account (gnatmake does) and are therefore incomplete. For example: all: foo foo: a.o b.o gcc -o $@ $< is not good enough, even when supplemented by generated source dependencies. Why? Because when CFLAGS contains -O3 or some explicit option, cross-unit inlining comes into the picture, so a.o does not depend on "just" b.o, it depends on a b.o compiled with the *same compiler options*. Make simply does not capture this dependency information. > The way it works is similar to all C stuff, someone has even named > it as dancing with a blade. Is it danger? Perhaps. Is it devil? Yes. > If someone fills that people in danger with that tool, please be so kind > to correct existing or to write a better tool, which is the right way, but Correcting make is impossible without breaking compatibility with existing makefiles. Therefore the only option is to replace make completely. gnatmake and gprbuild exist for this very purpose; so do all of the make alternatives mentioned elsewhere in this thread. > as for me I am sick and tired from advices about devil things (like > ada.calendar.time), those came from personal desire, and produce only > warring about a need (a requirement!) of restrictive use, without > constructive movement forward. The constructive movement forward is: use *existing* better tools. If you still *must* use make, do that non-recursively. > Do you plan to rewrite all these old good debian packages? No. I have *already* written all my Debian packages non-recursively and I routinely bypass upstream's fragile recursive makefiles with one non-recursive, simple makefile and one GNAT project file. And I usually specify .SUFFIXES in most of my Makefiles because the predefined rules just get in the way. BTW, many "old good Debian packages" are actually old and bad; this is being revealed by the growing number of build failures triggered by parallelism. To the point where many "old good Debian packages", rather than fixing or rewriting their recursive makefiles completely, disable parallel builds altogether. >> dependencies between Ada units like gnatmake does; therefore Make >> violates the Ada Reference manual. In short, when compiling Ada you >> *must* use gnatmake or its equivalent for another compiler than GNAT. >> And yo *must* use whatever configuration file is appropriate for >> gnatmake. > > *must* should better sounds with *can*, since this approach relates to > GNAT only. And as a consequence the GNAT compilation model approach can No. This approach exists with all Ada compilers and with several other languages that mandate the precise tracking of dependencies between compilation units like OCaml and, to a lesser extent, Java. > not turn makefile into a devil thing. This is the same as personal haircut > can not turn outer world into an ambiguous state. No. While a personal haircut creates no danger, recursive makefiles do create danger. > So here we can see when "none of these deficiencies" becomes a need to > establish environment capabilities in "tls/ssl and etc" dependencies. So > the correct answer here is that GNAT Ada has some deficiencies but in > general they are different from C approach. No. The reason for the existence of "configure" in AWS is because the external, optional dependencies are not written in Ada. In the Debian package for AWS, I bypass configure and upstream's makefile completely. Instead I use one non-recursive Makefile and one GNAT project file, as usual. This is fast and reliable. And I don't need to call configure because Debian allows me to control which external libraries must be present before building AWS. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 11:05 ` Ludovic Brenta @ 2012-07-30 11:33 ` Simon Wright 2012-07-30 12:16 ` Vasiliy Molostov 1 sibling, 0 replies; 65+ messages in thread From: Simon Wright @ 2012-07-30 11:33 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > Don't you see how wrong this approach is? > - The Makefile must call gcc -M to generate the dependencies and store > them in a file > - The Makefile *cannot* include the generated dependency file while it > runs > - therefore you must run make twice: (1) to generate the dependency info > and (2) to build using the dependency info. It's a while since I did this, but I'm pretty sure that (GNU) make knows that it has to re-read the generated dependency info. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 11:05 ` Ludovic Brenta 2012-07-30 11:33 ` Simon Wright @ 2012-07-30 12:16 ` Vasiliy Molostov 2012-07-30 12:48 ` Ludovic Brenta 1 sibling, 1 reply; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-30 12:16 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Mon, 30 Jul 2012 15:05:35 +0400: > Vasiliy Molostov wrote on comp.lang.ada: > Don't you see how wrong this approach is? Perhaps it is not ideal, but exists. > Add to that that Make dependencies do not take compiler flags into > account > (gnatmake does) and are therefore incomplete. For example: > > all: foo > foo: a.o b.o > gcc -o $@ $< > > is not good enough, even when supplemented by generated source > dependencies. Why? Because when CFLAGS contains -O3 or some explicit > option, cross-unit inlining comes into the picture, so a.o does not > depend > on "just" b.o, it depends on a b.o compiled with the *same compiler > options*. Make simply does not capture this dependency information. YOu can place compiler options into a separate dependant file. >> If someone fills that people in danger with that tool, please be so kind >> to correct existing or to write a better tool, which is the right way, >> but > > Correcting make is impossible without breaking compatibility with > existing > makefiles. Wooo. Indeed. > Therefore the only option is to replace make completely. > gnatmake and gprbuild exist for this very purpose; so do all of the make > alternatives mentioned elsewhere in this thread. Do you plan to replace it completely? > The constructive movement forward is: use *existing* better tools. > If you still *must* use make, do that non-recursively. *can*. The choice is mine, not your. > No. I have *already* written all my Debian packages non-recursively > and I routinely bypass upstream's fragile recursive makefiles with > one non-recursive, simple makefile and one GNAT project file. And > I usually specify .SUFFIXES in most of my Makefiles because the > predefined rules just get in the way. And it is good, any approach applicable, by the choice. > No. This approach exists with all Ada compilers and with several other > languages that mandate the precise tracking of dependencies between > compilation units like OCaml and, to a lesser extent, Java. I remember an *.alb file with compiler library level output collected in one file, which does not affect make tools too much. > No. While a personal haircut creates no danger, recursive makefiles do > create danger. If you are in danger it is not a recipe for any other people. I like my haircut, want to and will follow rules I specify by my own experience, without unconditionally accepting things that restricts a freedom of choice. > No. The reason for the existence of "configure" in AWS is because the > external, optional dependencies are not written in Ada. You tend to say that this issue is internal tls/ssl problem that they are dependencies to AWS? I suppose that this is an AWS issue to refer these dependencies and a lack of appropriate tool to examine these dependencies without 'configure' related things, that came from autotools. > In the Debian > package for AWS, I bypass configure and upstream's makefile completely. > Instead I use one non-recursive Makefile and one GNAT project file, as > usual. This is fast and reliable. Also, a good approach, and it is a matter of choice. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 12:16 ` Vasiliy Molostov @ 2012-07-30 12:48 ` Ludovic Brenta 2012-07-30 13:09 ` Vasiliy Molostov 0 siblings, 1 reply; 65+ messages in thread From: Ludovic Brenta @ 2012-07-30 12:48 UTC (permalink / raw) Vasiliy Molostov wrote on comp.lang.ada: > Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Mon, >> Don't you see how wrong this approach is? > > Perhaps it is not ideal, but exists. Yes. Just like the devil; he exists only because man created him. >> Add to that that Make dependencies do not take compiler flags >> into account (gnatmake does) and are therefore incomplete. >> For example: >> >> >> all: foo >> foo: a.o b.o >> gcc -o $@ $< >> >> >> is not good enough, even when supplemented by generated source >> dependencies. Why? Because when CFLAGS contains -O3 or some >> explicit option, cross-unit inlining comes into the picture, >> so a.o does not depend on "just" b.o, it depends on a b.o >> compiled with the *same compiler options*. Make simply does >> not capture this dependency information. > > You can place compiler options into a separate dependant file. I prefer to use gnatmake which already does the job. >> The constructive movement forward is: use *existing* better >> tools. If you still *must* use make, do that non-recursively. > > *can*. The choice is mine, not your. Sure. You can choose inferior tools, you can choose to shoot yourself in the foot, you can choose to ignore the devil, you can choose to spend your days tracking dependencies by hand and your nights debugging the ensuing dependency problems and you can choose to perpetuate the myth that glaring bugs in released software are a natural and unavoidable thing. But that will not make the devil disappear; it will have the opposite effect. And *I* choose to fight the devil. The first step is to know where he is. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-30 12:48 ` Ludovic Brenta @ 2012-07-30 13:09 ` Vasiliy Molostov 0 siblings, 0 replies; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-30 13:09 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Mon, 30 Jul 2012 16:48:36 +0400: >> Perhaps it is not ideal, but exists. > > Yes. Just like the devil; he exists only because man created him. > > And *I* choose to fight the devil. The first step is to > know where he is. Probably he lives along and within that man who created it. Warring and spelling against it can only make a man weak and a devil stronger. This is why Ada is a good anti-devil's solution, without warring. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 17:35 ` Vasiliy Molostov 2012-07-29 19:40 ` Dmitry A. Kazakov 2012-07-29 19:46 ` Robert A Duff @ 2012-07-30 6:06 ` Dirk Heinrichs 2 siblings, 0 replies; 65+ messages in thread From: Dirk Heinrichs @ 2012-07-30 6:06 UTC (permalink / raw) Vasiliy Molostov wrote: > More productive is recursive and parallel make. Nope. That makes the problem even worse. In a recursive, parallel build, the build can kind of overtake itself, which means that for example one library that needs relinking is itself linked into some executables before said relinking has been done, while other executables are linked to this library ofter its relinking has been done. Debugging this is real fun. Bye... Dirk -- Dirk Heinrichs <dirk.heinrichs@altum.de> Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 11:35 ` Nasser M. Abbasi 2012-07-29 12:29 ` Patrick @ 2012-07-29 12:31 ` Nasser M. Abbasi 2012-07-29 13:46 ` Ludovic Brenta 2012-07-29 13:54 ` Dmitry A. Kazakov 2012-07-30 5:57 ` General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?) Dirk Heinrichs 3 siblings, 1 reply; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-29 12:31 UTC (permalink / raw) I found why I can't tell gnatmake to use different folder for object and executable at the same time. It is all gnatbind fault ;) Here is a picture of how gnatmake works, found after many trials. I put the step number in (N) below, which represent the order of build step. main.adb | V (1) gnatmake -c | V main.o, main.ali ---------+ | | V | (2) gnatbind -x | | | V | b~main.ads | b~main.adb | | | V V +-----+---------+ | V (3) gnatlink main.ali -L/usr/lib -lblas -llapack | V main.exe the problem is that gnatbind has no option to send the b~* files to somewhere other than the folder it is in. i.e. the main.ali and the b~* files need to be in the same folder. Hence, it I send the main.ali to another folder from where the source file is after step (1), then gnatbind will fail in step(2). There is NO option to tell gnatbind to send the b~* files to another folder. And gnatlink in step(3) wants main.ali and the b~files to be in the same folder. big mess. So brute force build everything was the the easy way out for me for now (until and if I have time time to learn gpr :) --Nasser ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 12:31 ` Nasser M. Abbasi @ 2012-07-29 13:46 ` Ludovic Brenta 2012-07-29 14:15 ` Simon Wright 0 siblings, 1 reply; 65+ messages in thread From: Ludovic Brenta @ 2012-07-29 13:46 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > I found why I can't tell gnatmake to use different folder > for object and executable at the same time. Yes you can: for Object_Dir use "obj"; for Exec_Dir use "."; I do that all the time. Please read the doc. http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gnat_ugn_unw/Object-and-Exec-Directory.html#Object-and-Exec-Directory -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 13:46 ` Ludovic Brenta @ 2012-07-29 14:15 ` Simon Wright 0 siblings, 0 replies; 65+ messages in thread From: Simon Wright @ 2012-07-29 14:15 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > "Nasser M. Abbasi" <nma@12000.org> writes: >> I found why I can't tell gnatmake to use different folder >> for object and executable at the same time. > > Yes you can: > > for Object_Dir use "obj"; > for Exec_Dir use "."; Ludovic, Those are GPR features, and Nasser doesn't want to use GNAT Project. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 11:35 ` Nasser M. Abbasi 2012-07-29 12:29 ` Patrick 2012-07-29 12:31 ` Nasser M. Abbasi @ 2012-07-29 13:54 ` Dmitry A. Kazakov 2012-07-29 14:16 ` Nasser M. Abbasi 2012-07-30 5:57 ` General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?) Dirk Heinrichs 3 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2012-07-29 13:54 UTC (permalink / raw) On Sun, 29 Jul 2012 06:35:44 -0500, Nasser M. Abbasi wrote: > Well, I use Make. And this is the core problem. No matter how many times you would download a project that uses make your first problem would be to fix the makefile, confgure scripts etc. One of nice features GNAT has is that you don't need it anymore. P.S. I don't use make with any of Ada projects. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 13:54 ` Dmitry A. Kazakov @ 2012-07-29 14:16 ` Nasser M. Abbasi 2012-07-29 14:32 ` Dmitry A. Kazakov 0 siblings, 1 reply; 65+ messages in thread From: Nasser M. Abbasi @ 2012-07-29 14:16 UTC (permalink / raw) On 7/29/2012 8:54 AM, Dmitry A. Kazakov wrote: > On Sun, 29 Jul 2012 06:35:44 -0500, Nasser M. Abbasi wrote: > >> Well, I use Make. > > And this is the core problem. No matter how many times you would download a > project that uses make your first problem would be to fix the makefile, > confgure scripts etc. One of nice features GNAT has is that you don't need > it anymore. > > P.S. I don't use make with any of Ada projects. > Sure, I understand. As I said, I looked at gpr, and it seem like a nice build system for Ada. May be if I use Ada as much as you do, it will make more sense to use it. But for occasional use, make files are just easier for me to use, and they do the job for the small project I have now, and make integrate easier for me with what I have since I use make for everything else. --Nasser ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 14:16 ` Nasser M. Abbasi @ 2012-07-29 14:32 ` Dmitry A. Kazakov 0 siblings, 0 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2012-07-29 14:32 UTC (permalink / raw) On Sun, 29 Jul 2012 09:16:00 -0500, Nasser M. Abbasi wrote: > But for occasional use, make files are just easier > for me to use, That is because you already know make. But as a matter of fact for a small project gpr outperforms make by a league. Comparing a makefile with gpr-file for a small project, the latter will be at least twice shorter. If your project uses external libraries or other Ada projects it becomes drastically shorter. And as a bonus you get lots of useful stuff from GPS, like code base browsing, refactoring etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?) 2012-07-29 11:35 ` Nasser M. Abbasi ` (2 preceding siblings ...) 2012-07-29 13:54 ` Dmitry A. Kazakov @ 2012-07-30 5:57 ` Dirk Heinrichs 2012-07-30 10:50 ` Vasiliy Molostov 3 siblings, 1 reply; 65+ messages in thread From: Dirk Heinrichs @ 2012-07-30 5:57 UTC (permalink / raw) Nasser M. Abbasi wrote: > Yes, I understand. And when I build a Java application, the Java > programmers tell me to go use Ant build scripts as it is the best thing > also for building Java applications. Yes, those poor guys really think it is. To me, it's the worst build tool I've ever seen. > Make is not specialized to one task, but can do multiple tasks. It > might not be the best for one specific task, but it is the best > general tool for many many different things. No, it's not (You're talking about GNU make, right?). Today, there are some far better general build tools out there, which make GNU make look more like a toy than a serious tool. Some of it's most anoying weaknesses are: - Uses file timestamps instead of checksums (leads to unneeded recompilation and relinking in case of a simple comment ore white space change). - No builtin build cache (so there's no reuse of build results). - Doesn't detect changes in the commands it executes (so you are always forced to do a "make clean; make", especially when working in a team). Take a look at omake[1], makepp[2] or scons[3] if you want a really good general purpose build tool. Bye... Dirk [1]: http://omake.metaprl.org/index.html [2]: http://makepp.sourceforge.net/ [3]: http://www.scons.org/ -- Dirk Heinrichs <dirk.heinrichs@altum.de> Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?) 2012-07-30 5:57 ` General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?) Dirk Heinrichs @ 2012-07-30 10:50 ` Vasiliy Molostov 2012-07-30 11:10 ` Ludovic Brenta 0 siblings, 1 reply; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-30 10:50 UTC (permalink / raw) Dirk Heinrichs <dirk.heinrichs@altum.de> писал(а) в своём письме Mon, 30 Jul 2012 09:57:12 +0400: > Take a look at omake[1], makepp[2] or scons[3] if you want a really good > general purpose build tool. > > Bye... > > Dirk > > [1]: http://omake.metaprl.org/index.html > [2]: http://makepp.sourceforge.net/ > [3]: http://www.scons.org/ Good set of links, the question is why these are not so widely used in comparison to simple make? -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?) 2012-07-30 10:50 ` Vasiliy Molostov @ 2012-07-30 11:10 ` Ludovic Brenta 2012-07-30 12:39 ` Vasiliy Molostov 2012-08-30 10:49 ` General purpose build tools Stephen Leake 0 siblings, 2 replies; 65+ messages in thread From: Ludovic Brenta @ 2012-07-30 11:10 UTC (permalink / raw) >> [1]: http://omake.metaprl.org/index.html >> [2]: http://makepp.sourceforge.net/ >> [3]: http://www.scons.org/ > > Good set of links, the question is why these are not so widely used in > comparison to simple make? make is anything but simple. The reasons why the better tools are not used more widely are the same as the reasons why the better languages are not used more widely: - inertia. - ignorance. - lemming mentality. Sometimes inertia is a valid reason; it does not always make sense to rewrite massive makefiles, even when they are recursive and bug-ridden, because effort is better spent in other areas. One example of this is GCC. The other reasons apply to new projects. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?) 2012-07-30 11:10 ` Ludovic Brenta @ 2012-07-30 12:39 ` Vasiliy Molostov 2012-08-30 10:49 ` General purpose build tools Stephen Leake 1 sibling, 0 replies; 65+ messages in thread From: Vasiliy Molostov @ 2012-07-30 12:39 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Mon, 30 Jul 2012 15:10:27 +0400: >>> [1]: http://omake.metaprl.org/index.html >>> [2]: http://makepp.sourceforge.net/ >>> [3]: http://www.scons.org/ >> >> Good set of links, the question is why these are not so widely used in >> comparison to simple make? > > make is anything but simple. In general it is the same as any other tool like awk. It is still possible to use it for large project but the fact is that the convenience of that build system is held entirely on implementer/developer's conscience. > The reasons why the better tools are not used more widely are the same > as the reasons why the better languages are not used more widely: > > - inertia. > - ignorance. > - lemming mentality. The answer here is the cost of the effort. Experienced people does not insist on rewriting makefiles since they get what they awaiting from it, and nothing more, rewriting lead to expense of developer attention and its time, and possibly involves new bugs and mistakes, those can issue in more time and attention expense and which spending is not the goal of the development, in most cases. > Sometimes inertia is a valid reason; it does not always make sense to > rewrite massive makefiles, even when they are recursive and bug-ridden, > because effort is better spent in other areas. One example of this is > GCC. I name it conservative approach. No place for vogue rave in this field. And consider, that it is not a devil. Warrior spelling against devils - it is not the face of Ada approach, since such spelling is a way to hide own eyes, while existing things indeed just need attention more than we want to pay. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: General purpose build tools 2012-07-30 11:10 ` Ludovic Brenta 2012-07-30 12:39 ` Vasiliy Molostov @ 2012-08-30 10:49 ` Stephen Leake 1 sibling, 0 replies; 65+ messages in thread From: Stephen Leake @ 2012-08-30 10:49 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> writes: >>> [1]: http://omake.metaprl.org/index.html >>> [2]: http://makepp.sourceforge.net/ >>> [3]: http://www.scons.org/ >> >> Good set of links, the question is why these are not so widely used in >> comparison to simple make? > > make is anything but simple. > > The reasons why the better tools are not used more widely are the same > as the reasons why the better languages are not used more widely: > > - inertia. > - ignorance. > - lemming mentality. > > Sometimes inertia is a valid reason; it does not always make sense to > rewrite massive makefiles, even when they are recursive and bug-ridden, > because effort is better spent in other areas. One example of this is > GCC. Another aspect of inertia is learning time vs productivity gain. I've spent 20 years learning make, I'd rather not spend time on learning yet another build tool that won't increase my productivity very much; I'd rather spend that time doing something more fun. Looking at the web pages for these, I don't see any significant productivity gains for my projects. It would be nice to automatically generate Latex dependencies, but I don't write that many documents, and the ones I do write are simple enough or long/lived enough to make hand-written dependencies acceptable. On the other hand, it was clear right from the start that Ada offered significant productivity gains over C or C++, so that was well worth the change. > The other reasons apply to new projects. Tool knowledge applies even more to new projects; there are _lots_ of things to learn for a new project, why learn a new build tool unless it is clear it will be worth it? They also appear to be written in less-stable language. For example, the SCONS page says "The 2.x series drops support for all pre-2.4 versions of Python.". When was the last time GNU make said something like that? (I'm guessing never, certainly not since ANSI C came out). OMake is is written in OCaml; according to Wikipedia, there isno standard for that, and it is principally maintained by one company. Hmm. That's NRIA, which (according to Wikipedia) is a French National Institute. I'm not clear if that's better or worse than a for-profit company :(. Makepp is apparently written in Perl; I simply will not go there. I just don't want to worry about my build tool breaking when the underlying language changes. Of course, the main build tool for GNU Ada is gprbuild, which is maintained by one company, and it often breaks/changes from one release to another (not so much recently). That's only ok because I have a support contract. Can I pay for a support contract for OMake, Makepp, or SCONS? There's nothing about that on their home pages. To be fair, I don't have a support contract for make (just 20 years experience :). -- -- Stephe ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 9:31 how to tell gnatmake to send executables to a different directory when compiling multi source? Nasser M. Abbasi 2012-07-29 10:00 ` Dmitry A. Kazakov @ 2012-07-29 18:33 ` björn lundin 2012-07-29 19:06 ` onox 2012-07-31 11:12 ` Patrick 3 siblings, 0 replies; 65+ messages in thread From: björn lundin @ 2012-07-29 18:33 UTC (permalink / raw) On 29 Juli, 11:31, "Nasser M. Abbasi" <n...@12000.org> wrote: > I have --+---src/main1.adb, main2.adb > | > +---obj/ > | > +---bin/ > > In src/ I have few Ada main programs. I can build all and tell gnatmake > to send the *.o and *.ali to the obj/ directory using -D switch. > > But not able to find an option to tell it send the generated > executable (main1.exe and main2.exe) to bin/ directory. > I maintain a largish system, with 60+ executables, some libraries written in C/C++, linking with db-libraries on AIX, Windows and now Linux. The system was ported to gnat in 2002 by me, and at that time I found gpr files to be way to clumpsy. So I ended up with writing a frontend to gnatmake and gcc that * traversed the source dirs and created dummy ali files for each adb and ads file. * keeping a textfile as a 'ada library' ie, ability to have several object directories the frontend traverses the library file and builds a path of valid src dirs and object dirs and sets the ADA_INCLUDE_PATH resp ADA_OBJECT_PATH env vars. by invoking the frontend from the correct/wanted target directory, the frontend sets the env-vars, and runs gnatmake with a switch to honor the exiting, but empty, ali-files and links the exefile at the wanted location. the object files ends up in their correct locations. The only drawback is b* files generated by gnatbind. but the frontend moves them to the obj directory when the exe is created. This was driven by kornshell and bat files until a year ago, when I started to build on Linux. The kornshells (AIX) were not quite compatible with linux kornshell, so I scrapped that double implemenation and it is now driven by makefiles (yes recursive). One set of makefiles for all platforms. That is a ksh or bat calls the frontend, written in tcl, that calls gnatmake. it is stable and works very well. If I would do it again, today? No. Since that decision 10 years ago, gpr files has matured a lot. I would use gpr, but I'd still use make to drive all compilation. We also have some copying of different files to do, and auto generation of some souce code (Ada), and gpr does not handle that. Main reason to use gpr today would be c.l.a, where there are many experts on gpr. lots of help to get. With your own tools, you are on your own. Also eclipse/gps requires the use of gpr. /Björn Lundin ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 9:31 how to tell gnatmake to send executables to a different directory when compiling multi source? Nasser M. Abbasi 2012-07-29 10:00 ` Dmitry A. Kazakov 2012-07-29 18:33 ` how to tell gnatmake to send executables to a different directory when compiling multi source? björn lundin @ 2012-07-29 19:06 ` onox 2012-07-31 11:12 ` Patrick 3 siblings, 0 replies; 65+ messages in thread From: onox @ 2012-07-29 19:06 UTC (permalink / raw) Cc: nma Anyone who has heard of redo? (https://github.com/apenwarr/redo) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-29 9:31 how to tell gnatmake to send executables to a different directory when compiling multi source? Nasser M. Abbasi ` (2 preceding siblings ...) 2012-07-29 19:06 ` onox @ 2012-07-31 11:12 ` Patrick 2012-07-31 11:30 ` Dmitry A. Kazakov 2012-07-31 12:33 ` Ludovic Brenta 3 siblings, 2 replies; 65+ messages in thread From: Patrick @ 2012-07-31 11:12 UTC (permalink / raw) Cc: nma I have started a lot of threads in the past few months. I feel like i might be abusing this great resource. I hope I am not thread-jacking...... I was just wondering why GNAT does not use GPR. I spent 30 minutes last week sorting files into folders. I don't understand how GNAT works but just doing this gave me a rough outline of quite a lot of the project. It would help a lot if the project was already sorted by it's developers. Could a makefile not test for GPR and if present use it and if not dump all the files somewhere else and call the makefile that is already written for the project? In a perfect world, if there was a little readme in each folder and folders would be arranged by system, library etc and maybe folders like first stage, second stage etc it would make it a lot easier to follow along with. If the FSF had guidelines about folder layouts, then couldn't Adacore not just dump all the files in a folder to keep them happy before a commit? GNAT GPL is also laid out with all files in one folder, I can't see a reason for this. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-31 11:12 ` Patrick @ 2012-07-31 11:30 ` Dmitry A. Kazakov 2012-07-31 11:31 ` Dmitry A. Kazakov 2012-07-31 12:33 ` Ludovic Brenta 1 sibling, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2012-07-31 11:30 UTC (permalink / raw) On Tue, 31 Jul 2012 04:12:57 -0700 (PDT), Patrick wrote: > I spent 30 minutes last week sorting files into folders. I don't > understand how GNAT works but just doing this gave me a rough outline of > quite a lot of the project. It would help a lot if the project was > already sorted by it's developers. I wrote a small program that sorts out files and pushes them into standard GNAT directories registering the project for GPS. I didn't invested much work into it, though. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-31 11:30 ` Dmitry A. Kazakov @ 2012-07-31 11:31 ` Dmitry A. Kazakov 2012-07-31 11:34 ` Patrick 0 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2012-07-31 11:31 UTC (permalink / raw) On Tue, 31 Jul 2012 13:30:33 +0200, Dmitry A. Kazakov wrote: > On Tue, 31 Jul 2012 04:12:57 -0700 (PDT), Patrick wrote: > >> I spent 30 minutes last week sorting files into folders. I don't >> understand how GNAT works but just doing this gave me a rough outline of >> quite a lot of the project. It would help a lot if the project was >> already sorted by it's developers. > > I wrote a small program that sorts out files and pushes them into standard > GNAT directories registering the project for GPS. I didn't invested much > work into it, though. http://www.dmitry-kazakov.de/ada/gps_installer.htm -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-31 11:31 ` Dmitry A. Kazakov @ 2012-07-31 11:34 ` Patrick 0 siblings, 0 replies; 65+ messages in thread From: Patrick @ 2012-07-31 11:34 UTC (permalink / raw) Cc: mailbox Hi Dmitry Thanks for sharing this ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-31 11:12 ` Patrick 2012-07-31 11:30 ` Dmitry A. Kazakov @ 2012-07-31 12:33 ` Ludovic Brenta 2012-07-31 15:14 ` Patrick 1 sibling, 1 reply; 65+ messages in thread From: Ludovic Brenta @ 2012-07-31 12:33 UTC (permalink / raw) Patrick wrote on comp.lang.ada: > I was just wondering why GNAT does not use GPR. I spent 30 minutes > last week sorting files into folders. I don't understand how GNAT > works but just doing this gave me a rough outline of quite a lot > of the project. It would help a lot if the project was already > sorted by it's developers. Are you talking about the sources of GCC? They don't use project files because GCC grew from a C-only compiler to a "compiler collection" with front-ends, run-time libraries and tools for many languages besides Ada. And gnatmake, the tool that understands project files, is separate from the Ada front-end and from the libraries. And gprbuild, the tool that also understands project files but additionally understands several compilers for other languages, is not part of GCC. Also the inertia of GCC's extremely complex build machinery is huge. Nobody wants to or has the energy to rewrite 300_000 lines of configury, auto* and evil recursive makefiles (which are the result of 3 layers of generators) for no functional benefit and huge risk of breaking something :/ -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-31 12:33 ` Ludovic Brenta @ 2012-07-31 15:14 ` Patrick 2012-07-31 16:04 ` Ludovic Brenta 0 siblings, 1 reply; 65+ messages in thread From: Patrick @ 2012-07-31 15:14 UTC (permalink / raw) Hi Ludovic Yep, GCC looks really scary and I am sure if you want your compiler included in it, you have to do scary stuff too. What I am trying to say is that the GNAT project that Adacore is releasing directly to the public could have the option to build from GPR if possible and if not, it could fall back on Makefiles. I don't think it would be so hard to take a logically designed set of directories and then dump all the code out into one folder to hand over to the FSF people for GCC. I see what you are saying about gnatmake being separate but since Ada needs another version of Ada to compile, that computer might have gnatmake install already and if not then falling back on makefiles could work, no? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: how to tell gnatmake to send executables to a different directory when compiling multi source? 2012-07-31 15:14 ` Patrick @ 2012-07-31 16:04 ` Ludovic Brenta 0 siblings, 0 replies; 65+ messages in thread From: Ludovic Brenta @ 2012-07-31 16:04 UTC (permalink / raw) Patrick wrote on comp.lang.ada: > Yep, GCC looks really scary and I am sure if you want your compiler included in it, you have to do scary stuff too. > > What I am trying to say is that the GNAT project that Adacore is > releasing directly to the public *is* GCC, only a snapshot of AdaCore's branch in their version control system. > could have the option to build from GPR if possible and if not, it > could fall back on Makefiles. Double the work, no benefit. The other projects that AdaCore release (GPS, gprbuild, etc) do use project files extensively. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2012-09-07 1:22 UTC | newest] Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-29 9:31 how to tell gnatmake to send executables to a different directory when compiling multi source? Nasser M. Abbasi 2012-07-29 10:00 ` Dmitry A. Kazakov 2012-07-29 11:35 ` Nasser M. Abbasi 2012-07-29 12:29 ` Patrick 2012-07-29 13:02 ` Nasser M. Abbasi 2012-07-29 13:49 ` Ludovic Brenta 2012-07-29 14:09 ` Nasser M. Abbasi 2012-07-29 15:35 ` Ludovic Brenta 2012-07-29 15:42 ` Patrick 2012-07-29 16:41 ` Ludovic Brenta 2012-07-29 16:46 ` Patrick 2012-07-29 17:35 ` Vasiliy Molostov 2012-07-29 19:40 ` Dmitry A. Kazakov 2012-07-29 22:22 ` Vasiliy Molostov 2012-07-29 19:46 ` Robert A Duff 2012-07-30 0:20 ` Vasiliy Molostov 2012-07-30 3:01 ` Nasser M. Abbasi 2012-07-30 4:48 ` Nasser M. Abbasi 2012-07-30 21:05 ` Robert A Duff 2012-07-30 5:50 ` Dmitry A. Kazakov 2012-07-30 11:16 ` Vasiliy Molostov 2012-07-30 12:25 ` Georg Bauhaus 2012-07-30 12:59 ` Vasiliy Molostov 2012-07-30 14:07 ` Georg Bauhaus 2012-07-30 13:03 ` Nasser M. Abbasi 2012-07-30 14:02 ` Georg Bauhaus 2012-07-30 19:40 ` J-P. Rosen 2012-08-01 7:32 ` Miles Bader 2012-08-01 9:37 ` Ludovic Brenta 2012-08-02 5:01 ` Miles Bader 2012-08-01 15:15 ` J-P. Rosen 2012-08-02 15:08 ` Robert A Duff 2012-08-02 16:37 ` J-P. Rosen 2012-07-30 19:50 ` Ludovic Brenta 2012-07-30 3:21 ` Nasser M. Abbasi 2012-07-30 8:19 ` Simon Wright 2012-07-30 6:12 ` Dirk Heinrichs 2012-07-30 6:40 ` Ludovic Brenta 2012-07-30 10:31 ` Vasiliy Molostov 2012-07-30 11:05 ` Ludovic Brenta 2012-07-30 11:33 ` Simon Wright 2012-07-30 12:16 ` Vasiliy Molostov 2012-07-30 12:48 ` Ludovic Brenta 2012-07-30 13:09 ` Vasiliy Molostov 2012-07-30 6:06 ` Dirk Heinrichs 2012-07-29 12:31 ` Nasser M. Abbasi 2012-07-29 13:46 ` Ludovic Brenta 2012-07-29 14:15 ` Simon Wright 2012-07-29 13:54 ` Dmitry A. Kazakov 2012-07-29 14:16 ` Nasser M. Abbasi 2012-07-29 14:32 ` Dmitry A. Kazakov 2012-07-30 5:57 ` General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?) Dirk Heinrichs 2012-07-30 10:50 ` Vasiliy Molostov 2012-07-30 11:10 ` Ludovic Brenta 2012-07-30 12:39 ` Vasiliy Molostov 2012-08-30 10:49 ` General purpose build tools Stephen Leake 2012-07-29 18:33 ` how to tell gnatmake to send executables to a different directory when compiling multi source? björn lundin 2012-07-29 19:06 ` onox 2012-07-31 11:12 ` Patrick 2012-07-31 11:30 ` Dmitry A. Kazakov 2012-07-31 11:31 ` Dmitry A. Kazakov 2012-07-31 11:34 ` Patrick 2012-07-31 12:33 ` Ludovic Brenta 2012-07-31 15:14 ` Patrick 2012-07-31 16:04 ` Ludovic Brenta
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox