[Q-e-developers] [Pw_forum] Compilation of PW
Samuel Poncé
samuel.pon at gmail.com
Tue Mar 29 19:44:49 CEST 2016
Hi Paolo,
Sorry, I meant "the only way I found".
I was not aware of the "make depend" that does exactly what I want for the
test farm.
I think that it is not exactly equivalent to "/install/makedeps.sh" because
of the libiotk and the version that I was mentioning in my last email.
Thank you very much !
Best,
Samuel
On 29 March 2016 at 16:45, Paolo Giannozzi <p.giannozzi at gmail.com> wrote:
> On Tue, Mar 29, 2016 at 3:56 PM, Samuel Poncé <samuel.pon at gmail.com>
> wrote:
>
>>
>> Indeed, the only way to make it work is to do the following:
>>
>
> the only way? it has always been working perfectly for me. "make depend",
> or equivalently /install/makedeps.sh, should be run on a working (compiled
> or at least properly unpacked) QE distribution, only when something changes
> in the dependency tree, and the changed make.depend files should be
> committed together with other changes. No need to run it all the time. No
> need either to make it more complex.
>
> Paolo
>
>>
>> ------------------------------------------------------------------
>> make veryclean
>> ./configure
>>
>> make -C Modules version
>>
>> cd install;gzip -dc ../archive/iotk-1.2.beta.tar.gz | (cd ../; tar -xvf
>> -)
>> cp iotk_config.h ../S3DE/iotk/include/iotk_config.h
>> cd ../; ln -fs S3DE/iotk iotk
>>
>> sh install/makedeps.sh
>> -----------------------------------------------------------------
>>
>
>> Therefore those lines should be included either in the configure or in
>> the install/makedeps.sh script.
>>
>> I can commit the change if you wish? Would you prefer to have that in
>> "configure" or in "makedeps.sh" ?
>>
>
>> Best,
>>
>> Samuel & Martin
>>
>>
>>
>> On 28 March 2016 at 16:56, Filippo Spiga <
>> filippo.spiga at quantum-espresso.org> wrote:
>>
>>> Hello Samuel,
>>>
>>> On 28 Mar 2016, at 16:18, Samuel Poncé <samuel.pon at gmail.com> wrote:
>>> > Concerning the limitation of the number of commits, I guess the
>>> problem is that the .svn history starts to be huge.
>>>
>>> I do not see a problem here, "huge" in term of number of commits or
>>> "huge" in term of space? For the second case, there are bigger SVN
>>> repositories on QE-FORGE. "q-e" is ok-ish.
>>>
>>> A fresh SVN checkout takes time but a fresh GIT clone is way faster. The
>>> GIT mirror simplifies a lof of network operations because of the way GIT is
>>> engineered compared to SVN. I had a proposal for mixed SVN-GIT that can be
>>> a candidate solution to avoid "waterfall commits" but it requires people to
>>> change a bit their way of contributing and a more pro-active way of
>>> branching and merging.
>>>
>>>
>>> > There is also the problem of qe-forge being temporarily inaccessible
>>> after a commit (this one is weird).
>>>
>>> I wish I can tell why this happen, I suspect it is a hook script in the
>>> current QE-FORGE that has been activated automatically while doing cleaning
>>> routine operations on the server side. The problem may naturally disappear
>>> when we move to a new QE-FORGE portal. No ETA is defined yet but it must
>>> happen before September.
>>>
>>>
>>> > A suggestion might be to restart clean at the next major QE release,
>>> off course saving the history file somewhere?
>>>
>>> This is something I personally prefer to avoid. During the migration of
>>> the SVN repository on the new QE-FORGE we will have the opportunity to
>>> delete completely all inactive branches and purge away very old big files
>>> stored at the early stages of the repository history. This will make the
>>> "size" smaller while keeping full historical record.
>>>
>>> I will discourage the discontinuity of the SVN legacy repository unless
>>> drastically changes the collaborative development are applied. IMHO the
>>> community is not ready.
>>>
>>> I hope this topic (that is bery important to ensure sustainability of QE
>>> project going forward) will be on the agenda of the next plenary QE
>>> developer meeting early 2017.
>>>
>>> Cheers
>>>
>>> --
>>> Filippo SPIGA
>>> * Sent from my iPhone, sorry for typos *
>>>
>>>
>>> _______________________________________________
>>> Q-e-developers mailing list
>>> Q-e-developers at qe-forge.org
>>> http://qe-forge.org/mailman/listinfo/q-e-developers
>>>
>>
>>
>>
>> --
>>
>> ------------------------------------------------------------------------------------------------
>> Dr. Samuel Poncé
>> Department of Materials
>> University of Oxford
>> Parks Road
>> Oxford OX1 3PH, UK
>>
>> Phone: +44 1865 612789
>> email: samuel.ponce at materials.ox.ac.uk <fabio.caruso at materials.ox.ac.uk>
>> web: http://giustino.materials.ox.ac.uk/index.php/Site/SamuelPonc%e9
>> ------------------------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Q-e-developers mailing list
>> Q-e-developers at qe-forge.org
>> http://qe-forge.org/mailman/listinfo/q-e-developers
>>
>>
>
>
> --
> Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers
>
>
--
------------------------------------------------------------------------------------------------
Dr. Samuel Poncé
Department of Materials
University of Oxford
Parks Road
Oxford OX1 3PH, UK
Phone: +44 1865 612789
email: samuel.ponce at materials.ox.ac.uk <fabio.caruso at materials.ox.ac.uk>
web: http://giustino.materials.ox.ac.uk/index.php/Site/SamuelPonc%e9
------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20160329/5a811727/attachment.html>
More information about the developers
mailing list