trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2012

Re: [trinity-devel] Howto handle differing versions of libtool in TDE builds

From: Darrell Anderson <humanreadable@...>
Date: Tue, 20 Mar 2012 06:32:12 -0700 (PDT)
> Yes, that is frustrating because it shows that the TDE
> autotool/libtool code is no longer compatible with the current libtool/autofoo tools.
> That's just something we have to overcome. I think cmake conversion
> would resolve this issue, but I don't even know where to start. I've just
> skipped tdeutils for now, but that will be a mandatory package to fix building on
> before R14 or building will break for all distros when they update to the current
> stable libtool.

Yes, we have to deal with this sooner or later. I was only offering that later is more palatable if we want to release R14 in a timely manner.

Converting to cmake would resolve many issues. I have raised that topic too. I have asked for somebody to write a basic how-to for the wiki so others can help with the process. A few people have noted there are scripts to help with the automation. Those of us new to the process could use the wiki article to start converting smaller packages.

We have no quality assurance plan to ensure that cmake conversions are complete. I filed a bug report against all cmake packages because none support kerberos (krb5). Reading past list threads and the related etherpad indicates many little pieces here and there are missing. What has been converted is wonderful and does indeed work. I'm grateful for that effort. I'm just saying we need a check list to ensure the minute details are converted too. I am aware that a full conversion requires a person to have all related software installed in order to test. A check list helps others with that software to fill the remaining gaps.

That is why I am not in favor of destroying any of the automake files after a cmake conversion. Those files serve as our guide.

Similarly, all or most of the TDE packages come with a text file called subdirs, which was used in the KDE3 days with the DO_NOT_COMPILE environment variable to determine which package components to build. That subdirs text file is a good start for a check list. Each component listed in the file needs an equivalent -DWITH_COMPONENT build option.

When packages no longer build because of libtools/automake updates then file the bug report. Tag the report as Blocker P1 and note in the comments the problem is a build issue.

Darrell