Re: [MoM] Any progress?
Andreas,
On Mon, Feb 20, 2012 at 3:53 PM, Andreas Tille <andreas@an3as.eu> wrote:
> Hi Luis,
>
> On Mon, Feb 20, 2012 at 12:41:06PM -0500, Luis Ibanez wrote:
>> I passed the weekend experimenting with cmake-ifying fis-gtm:
>>
>> https://github.com/luisibanez/fis-gtm/tree/cmakeified
>
> Ahhh, interesting approach. The choice of cmake is probably based by
> your experiences at kitware.com - but that's fine.
>
Guilty as charged... :-)
>> Current Status:
>> ---------------------
>>
>> Here are the two main issues that we have observed
>>
>> A) Using pbuilder, the build fails when looking for a 32 bits header.
>>
>> The culprit here seems to be the use of the -I- option.
>>
>> Experiments, and conversation with fis-gtm developer showed
>> that "-iquote" is not a full replacement for "-I-", and that the quick
>> way to get through this obstacle is to copy the headers from the
>> platform-specific directory (sr_i386 or sr_x86_64) on top of the
>> files in sr_port directory (and maybe others too).
>>
>> BTW: I manage to build locally by using "debuild", but in Andreas'
>> environment "debuild" fails. So, there may still be some lose cables
>> in the configuration and build process beyond what we are observing
>> with pbuilder.
>
> I admit that this is a strange issue which I never faced before.
> Usualle debuild (or rather more precisely pdebuild which creates a clean
> chroot) is perfectly reproducible.
>
>> B) In the Installation step, the ./pro/gtminstall file is not being found.
>>
>> Here we are suspecting that the file has been removed, between
>> the time that it was created during the build stage, and the time
>> that we get to the installation stage.
>>
>>
>>
>> Current paths of action:
>> ---------------------------------
>>
>> The exploration on cmake-ifying fis-gtm, was an alternative to solve (A),
>> or at least to get familiar enough with the fis-gtm configuration as to
>> move files around before the build process is triggered.
>>
>> I'm keeping (B) on hold until I get some more progress on (A).
>>
>> After what I learned with the cmake-ification exercise, I'm planning
>> on heading the way of copying the architecture specific directories
>> on top of the sr_port directory, or even better, copying all headers
>> (in the right order) into a temp directory and only put that directory
>> in the include search path. The trick here is to determine the proper
>> order to copy the files, so that the architecture specific files override
>> the generic ones.
>>
>>
>> All suggestions and advice are very welcome...
>
> When reading the following please consider that all I'm writing is not
> based on technical understanding of fis-gtm but I'm rather expressing a
> gut feeling based of past experience with other programs. It might be
> wrong and should be considered with a grain of salt.
>
> I have the strong feeling that fis-gtm could profit from some kind of
> modern build system, so in principle I think what you are trying to do
> is a good move for upstream fis-gtm. My prejudice that you should know
> cmake tricks well enough from your work at kitware makes cmake a
> straightforeward choice for you and the step sounds logical. However,
> if I were in your shoes I would try to make pretty sure that other
> fis-gtm upstream are really happy about this step. If this is the case
> I would really applause your plan because it not only would make fis-gtm
> easier to package from a Debian point of view but it also might simplify
> integration into other distributions and will make fis-gtm probably more
> widely accepted.
>
Yes, those are all factors that played in taking this exploration route.
Among the extra candy that a cmake-base build process could bring
to bear here is the "potential" for building GTM in Macs and MinGW,
which can be a great step towards wide adoption of M / MUMPS in
different platforms.
> On the other hand if the cmake stuff will not be accepted for main
> fis-gtm distribution you will end up with a large patch set which is
> hard to maintain. It depends a bit what will happen with the final
> fis-gtm packaging where I do see two options:
>
> 1. Cmake based build will never require any running fis-gtm any more
> In this case I would really strongly hope upstream would accept
> this because this would be a really big simplification.
> 2. The Cmake stuff is only applied to get the initial packaging done
> and dropped later in favour to build all following fis-gtm packages
> using the previous fis-gtm as build-depends - in other words follow
> our original plan and just use cmake to circumvent the initial
> problems. This does not really require the acceptance from upstream
> for your changes.
>
> Both options would work (even if I'd regard 1. as the ideal one).
> However, if you try to apply the cmake patchset on top of every new
> fis-gtm source release I would not regard this as a sustainable solution
> for the future. In this case I'd rather tend to try to get plan B
> working.
>
You bring up great points here.
Yes, I should talk more with Bhaskar about the chances
of CMake being adopted upstream at some point.
One advantage of the way CMake is applied here is that
it comes down to simply adding a set of CMakeLists.txt
files in every directory (10 files up to this point). Should
the cmake build process not be embraced upstream,
these cmake files could still be part of the set of "extra"
files that are are applying now.
Of course, it is always better if changes made it upstream.
At this point, I'm in a bit of a catch 22 situation, where I needed
to show that the approach have some promise (some good
chances of working), before trying to promote it more upstream.
The current experiment is not yet to the point where we can
claim that fis-gtm can be configured with cmake, so I may still
have to spend some quality time with it before promoting it
too much.
> Hope this helps to make a good decision. For other more detailed advise
> I need more info. Your link to your github directory was not really
> helpful for me because if I prepend a "git clone" and try to download
> this repository this fails.
mm,
this is my bad, because I pasted the URL
of the git html viewer:
https://github.com/luisibanez/fis-gtm
that is just good for using a web browser to go through
the code, while for cloning, the URL that is useful is:
git://github.com/luisibanez/fis-gtm.git
so, you can clone with :
git clone git://github.com/luisibanez/fis-gtm.git
and then get to the "cmakeified" branch with:
git checkout --track origin/cmakefied
then,
create a binary directory to build fis-gtm
outside of the source tree.
For example:
(assuming that you cloned fis-gtm in the
directory ~/src/fis-gtm)
mkdir /tmp/fis-gtm-build
cd /tmp/fis-gtm-build
ccmake ~/src/fis-gtm
make
This works for me in 32 bits, (not yet in 64 bits)
up to the point of compiling the .c files into .o and
creating libraries with them. The next step would
be to set up the build of executables...
and then see if they work... :-)
> Please be patient with me as a git beginner
> and explain how I can download the repository to enable me inspecting
> your changes directly (if you want me to do so - but I'm also no cmake
> expert and just cross fingers if I need to build a cmake based program).
>
> Kind regards and thanks for the status update
>
I'll try to make some progress on this in the
following days, but I'm also dealing with some
deadlines, so, I may not be able to put as much
time on this effort as I would like,...
Things in the calendar are looking
better after Thursday.
Luis
Reply to: