[AWS] building AWS error

David Marceau davidmarceau@sympatico.ca
Sat, 12 Jul 2003 13:05:34 -0400


Pascal Obry wrote:
> 
> David,
> 
>  > Solution:
>  > --------
>  > Here is the recipe I would recommend being in the makefiles and the
>  > configuration files:
>  > 0)install "msys" unix tools for windows os.
>  > 1)set the ADA_INCLUDE_PATH to wherever /adainclude is
>  > 2)set the ADA_OBJECTS_PATH to wherever /adalib is
> 
> Why do you think 1 and 2 are needed ?
Actually, for just compiling examples in the gnat examples directory it
is not necessary.
However for any other project for example adagtk, adawebserver, xmlada,
adasockets....
I sincerely think this is a good preparatory measure for the
includes/run-time-paths to come.
It is also a good idea in my humble opinion to be explicit as to what
tools are necessary in the configuration and
to show the exact details of their usage.  Among these are the preceding
ada paths....
> 
>  > 3)set the PATH to point typically to c:/gnat/bin
>  > 4)In the makefile.conf file declare the following variables:
>  > AR=c:\gnat\bin\ar
>  > CP=c:\msys\1.0\bin\cp -p
>  > RM=c:\msys\1.0\bin\rm
>  > MAKE=c:\gnat\bin\make
>  > GREP=c:\msys\1.0\bin\grep
>  > DIFF=c:\msys\1.0\bin\diff
>  > SED=c:\msys\1.0\bin\sed
> 
> I think it is better to set the PATH to point to the MSYS bin directory here.
Tend to disagree here because there are many things in the makefile and
the makefile.conf that seem to be passed off as understood.
If that was the case the compile would have built the first time
correctly for Ada Web Server without any question.
I am simply trying to clarify all the details in order for this
situation to be prevented in the future and also to 
save the AWS team support time :)


>I think it is better to set the PATH to point to the MSYS bin
>directory here.

Also to support my argument I have seen the same kind of errors happen
even with msys in the path.
I am only suggesting the above stuff as a preventitive measure and also
to liberate this stuff from the PATH environment variable 
-------------------------------emphasis here---------------
in order to isolate what is getting used and where with no room for
probability of something else running instead.
---------------------------------
There are times in my past where there were two different versions of an
executable in two different directories of which both were in the
path...i.e. gcc.  Yes is true that it does go for the first path dir.
but I don't recommend depending on the order of the path statements in
order for an expected exe to run.  This is analogous to the weird stuff
I have also seen concerning two versions of source
headers/adaincludes/adaobject of which were in the wrong order in the
path.  All this to say I sincerely think it is best to have an explicit
environment variable for these kinds of things in order to be able to
say...."Yes it really is that version of that ada include I am using", 
"yes it really is that version of msys's grep, cp, whatever... I am
definitely using."

It might seem this is overkill but it does save time when isolating
problems with configuration in the long run in my opinion.
It does follow the ada mentality of lots of effort on the deliberation
before coding.  It's just an extension of that focused on the
configuration of the environment.

I hope this helps :)

Santé bonheur,
David Marceau