how to tell gnatmake to send executables to a different directory when compiling multi source?

how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Dmitry A. Kazakov]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Patrick]

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!)

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

"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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Dmitry A. Kazakov]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Simon Wright]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Dmitry A. Kazakov]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

"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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Patrick]

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 :)

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Patrick]

okay, thanks again

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Vasiliy Molostov]

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/

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[björn lundin]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[onox]

Anyone who has heard of redo? (https://github.com/apenwarr/redo)

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Dmitry A. Kazakov]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Robert A Duff]

"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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Vasiliy Molostov]

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/

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Vasiliy Molostov]

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/

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Dmitry A. Kazakov]

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

General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?)

[Dirk Heinrichs]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Dirk Heinrichs]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Dirk Heinrichs]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

"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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Simon Wright]

"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).

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Vasiliy Molostov]

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/

Re: General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?)

[Vasiliy Molostov]

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/

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

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.

Re: General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?)

[Ludovic Brenta]

>> [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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Vasiliy Molostov]

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/

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Simon Wright]

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. 

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Vasiliy Molostov]

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/

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Georg Bauhaus]

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.

Re: General purpose build tools (was: Re: how to tell gnatmake to send executables to a different directory when compiling multi source?)

[Vasiliy Molostov]

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/

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Vasiliy Molostov]

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/

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Nasser M. Abbasi]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Vasiliy Molostov]

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/

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Georg Bauhaus]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Georg Bauhaus]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[J-P. Rosen]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

"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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Robert A Duff]

"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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Patrick]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Dmitry A. Kazakov]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Dmitry A. Kazakov]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Patrick]

Hi Dmitry

Thanks for sharing this

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Patrick]

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?

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Miles Bader]

"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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Ludovic Brenta]

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.

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[J-P. Rosen]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Miles Bader]

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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[Robert A Duff]

"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

Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

[J-P. Rosen]

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

Re: General purpose build tools

[Stephen Leake]

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