Windows porting (MinGW)

[roccoarpa]

I'm opening temporarily this pull request to track down the developments for bitpit's Windows porting through msys2/mingw.
Personally, I've fully tested it on local Win10 machines, and it works. I've just some doubts on the final expected results of some modules examples, but i think it's something related to my lack-of-knowledge.
@edoardolombardi @marcocisternino, as far as you know, before officially asking the final review/merge to @andrea-iob , do we need more testing on this branch?

Let me know your opinion, just to decide how to proceed.

[edoardolombardi]

Even on my machine compilation and testing are ok.

[marcocisternino]

Let's merge! M Ottieni Outlook per Android<https://aka.ms/ghei36>

…

________________________________ From: Edoardo Lombardi <notifications@github.com> Sent: Thursday, July 16, 2020 7:46:33 PM To: optimad/bitpit <bitpit@noreply.github.com> Cc: Marco Cisternino <marco.cisternino@optimad.it>; Mention <mention@noreply.github.com> Subject: Re: [optimad/bitpit] Windows porting (MinGW) (#75) Even on my machine compilation and testing are ok. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#75 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABSMIGFZBVLHNMYCJ2QNZQLR344HTANCNFSM4O2MUMXA>.

[andrea-iob]

There is one more issue I would like to address before merging the branch into the master (I'm not sure if I've already reported it in the review). I think it's better to remove the duplicates from the variable BITPIT_EXTERNAL_LIBRARIES itself, rather than creating a new variable. Also, I'm not sure if the function REMOVE_DUPLICATES works properly in this case. If the list of external libraries is something like "library_1.a libmpi.a library_2.a libmpi.a", removing the duplicates would give us "library_1.a libmpi.a library_2.a", but this will not work if library_2.a depend on libmpi.

[roccoarpa]

There is one more issue I would like to address before merging the branch into the master (I'm not sure if I've already reported it in the review). I think it's better to remove the duplicates from the variable BITPIT_EXTERNAL_LIBRARIES itself, rather than creating a new variable. Also, I'm not sure if the function REMOVE_DUPLICATES works properly in this case. If the list of external libraries is something like "library_1.a libmpi.a library_2.a libmpi.a", removing the duplicates would give us "library_1.a libmpi.a library_2.a", but this will not work if library_2.a depend on libmpi.

Look, I did some further tests and I realized this REMOVE_DUPLICATES story was really unnecessary to land the commit. So nevermind. I will push an updated version shortly. Hope it satisfies your requests.

[andrea-iob]

In my opinion, the problem with the PETSc static library will arise also for all other static variables. I think it would be better to remove all static variables from the list of external libraries exported by bitpit. I've added this change in commit c8aea1d. I've also moved the definition of PETSC_ARCH and PETSC_DIR before finding PETSc package (13463d9).

@marcocisternino confirms that the updated branch compiles on Windows.

If @roccoarpa confirms that the changes are fine we can merge into master.

[roccoarpa]

In my opinion, the problem with the PETSc static library will arise also for all other static variables. I think it would be better to remove all static variables from the list of external libraries exported by bitpit. I've added this change in commit c8aea1d. I've also moved the definition of PETSC_ARCH and PETSC_DIR before finding PETSc package (13463d9).

@marcocisternino confirms that the updated branch compiles on Windows.

If @roccoarpa confirms that the changes are fine we can merge into master.

From my side all I need is that the full, shared(dll.a or dll) compiled bitpit can be included in a external project who explicitly uses a cmake find_package(BITPIT) command to retrieve it, without arising dependencies conflicts. If your new modifications/commits achieve it, they are fine for me. Regards.