Re: [MoM] Any progress?
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.
> 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.
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.
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. 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
Andreas.
--
http://fam-tille.de
Reply to: