[Q-e-developers] makedeps.sh

[Riccardo Di Meo]

On 04/19/2011 08:30 PM, Paolo Giannozzi wrote:
>
> On Apr 19, 2011, at 12:49 , Riccardo Di Meo wrote:
>
>> In particular, the file makedeps.sh came to my attention and I was
>> asking myself if it is supposed to be used by some configure related
>> script dynamically
>
> no, it used to be that way, but no longer. From the developer manual:
>
>   When you modify the program sources, run the
> \texttt{install/makedeps.sh}
>   script  or type \texttt{make depend}  to update files
> \texttt{make.depend} in
>   the various subdirectories.

thank you for the explanation (and my apologies for not having looked it 
up myself: I didn't noticed/forgot there was a developer manual...)

>
>> I have also noticed that such script seems to work fine if the espresso
>> source tree is at least partially compiled (at least up to the iotk) but
>> it seems not to work if I start from a fresh directory/distclean
>> configuration.
>
> it requires iotk to be properly unpackaged, since one of the modules
> used by QE is there

this explains the various @iotk around the make.depend when executed 
without unpacking  :)

>
>> Last thing: using the aforementioned trick (configure/make and then
>> makedeps.sh)
>
> configure/make and then nothing more

the configure/make/makedeps (which will become "tar iotk/makedeps" with 
the knowledge now acquired) is necessary for the MS2, since it inserts 
some modules in the the QE distribution (the alternative being that of 
patching the make.depend programmatically (a less robust solution if the 
first is available IMO).

>
>> the script seems to work fine, however, at least in my case, looks
>> like it's fooled by an #include "something.f90" which I have in my
>> code (I know it isn't good practice, however it avoids a circular
>> dependency)
>
> if there is a circular dependency, it must be removed. If there isn't
> any, no

not that there is any alternative anyway (at least in Fortran)... :)

> need to use nonstandard tricks.

the use of the include is there actually to keep the source code tidy 
and clean, rather than for practical purposes: I could have just cut'n 
copied the functions in the module that includes them, however it would 
have mixed sources that do different things (and more importantly, that 
need to be tweaked by different people).

Thank you for your time and patience,
Riccardo Di Meo

>
> P.
> ---
> Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
>
>
>