bjoo
commented
7 years ago Ubuntu should have a libxml2. I think it is called libxml2-dev. We could use that. Either we could give qdp++ no —with-libxml2 option or we can point it to /usr/local
From what I could read, packaging for Debian may not be very hard. The question is whether we could for example build it in travis, and then export the package. That way we could use the same travis.yml and travis_ci.sh to ensure we set up the same compiler and MPI.
I can do a little reading about this perhaps. Best, B
On Jun 28, 2017, at 11:02 AM, Martin Ueding notifications@github.com wrote:
The whole run time on Travis CI is limited to 50 minutes. In that time we need to do a lot of things:
Add Ubuntu packet source and update package meta data. On Debian, this always takes ages. Install GCC 6 and OpenMPI. This again takes quite a while. Download, configure and build libxml2. Compilation is usually fast thanks to ccache but Autotools wastes a lot of our precious build time. Either we use a package from the distribution of make our own package. Download, configure and build QMP. Need to package this. Download, configure and build QDP++. This takes even longer to configure because of the submodules. QPhiX: Configure outer level Compile codegen (cached with ccache) Generate code Generate specialization headers Compile kernel code (cached with ccache) Compile QPhiX test cases Actually run the tests The QPhiX stuff should better be run every time, we do want to test this. The other stuff is not relevant here and there are no significant API breaking changes to expect. So we will have to do the following:
Speed up libxml2 Provide a package of QMP for Ubuntu 14.04 with GCC 6 Provide a package of QDP++ for Ubuntu 14.04 with GCC 6 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_qphix_issues_80&d=DwMCaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=SC-qvz5njMoFH6cliT5XZQ&m=9hVsc5UKi8vJD1zsFdeLaodaoN5npJpxvCETb7kf2aQ&s=843ErahccO47ELyOWZYrqnztbK8SEwTWViCKu9jQYtE&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAj16PdEWc0kh5qmvWYMxB9mkH7JXLIfks5sIhadgaJpZM4OHrw3&d=DwMCaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=SC-qvz5njMoFH6cliT5XZQ&m=9hVsc5UKi8vJD1zsFdeLaodaoN5npJpxvCETb7kf2aQ&s=gZmzv-i9_W8MU_ULFUTNT7A_L6sZ9UCr4On1mAnLYfI&e=.
martin-ueding
The whole run time on Travis CI is limited to 50 minutes. In that time we need to do a lot of things:
ccachebut Autotools wastes a lot of our precious build time. Either we use a package from the distribution of make our own package.ccache)ccache)We already have the problem that we cannot compile for the AVX2 and KNL architectures, this is bad enough. Now we have the issue that the added multi-shift test pushes us beyond those 50 minutes for AVX (scalar still works) and we are about to lose another architecture.
The QPhiX stuff should better be run every time, we do want to test this. The other stuff is not relevant here and there are no significant API breaking changes to expect. So we will have to do the following: