Automated migration of FileZilla libraries

Moderator: Project members

Post Reply
Message
Author
sim0s
504 Command not implemented
Posts: 9
Joined: 2017-01-27 14:42
First name: Simos
Last name: Gerasimou

Automated migration of FileZilla libraries

#1 Post by sim0s » 2017-03-28 13:54

Hi,

Context:
I'm doing research on library migration. I'm testing a semi-automated approach for transforming a software project that uses an obsolete third-party library to start using another functionally-equivalent library.

As has been noted in a recent post in FileZilla's development diary, FileZilla used different XML libraries, i.e., old FileZilla versions used TinyXML and new FileZilla versions use PugiXML.

Problem:
I've applied the semi-automated transformation approach on FileZilla 3.11 (which used TinyXML) and:
  • generated a set of new header and source files; for simplicity assume that only two files are generated, i.e., TinyXMLNew.h and TineXMLNew.cpp
  • changed all the necessary (I think) configuration files, i.e., configure.ac, src/Makefile.am, src/interface/Makefile.am,
  • created an fz_check_tinyxmlnew.m4 in m4 directory and applied the necessary renamings
  • defined the necessary Makefile.am in src/TinyXMLNew based on src/tinyxml/Makefile.am
  • reconfigured the project using autoreconf -i -m configure.ac
  • ran the script for compiling FileZilla on OSX available at this post
When I try to compile and install FileZilla, the generated configure file throws an error towards the end of the script (~ line 18900):

Code: Select all

set dummy xdg-open; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
$as_echo_n "checking for $ac_word... " >&6; }
if ${ac_cv_path_xdgopen+:} false; then :
  $as_echo_n "(cached) " >&6
else
  case $xdgopen in
  \\/* | ?:\\/*
fi

  ac_cv_path_xdgopen="$xdgopen" # Let the user override the test with a path.
  ;;
  *)
  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
  IFS=$as_save_IFS
  test -z "$as_dir" && as_dir=.
    for ac_exec_ext in '' $ac_executable_extensions; do
  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
    ac_cv_path_xdgopen="$as_dir/$ac_word$ac_exec_ext"
    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
    break 2
  fi
done
  done
IFS=$as_save_IFS

  ;;
esac
fi
I tried unsuccessfully to resolve the error.

Any help/ideas about this problem and how to resolve it would be greatly appreciated.

Thanks,
Simos

User avatar
botg
Site Admin
Posts: 33428
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: Automated migration of FileZilla libraries

#2 Post by botg » 2017-03-28 14:40

configure is a generated file, I suppose the error is either in configure.ac or one of the .m4 files.

sim0s
504 Command not implemented
Posts: 9
Joined: 2017-01-27 14:42
First name: Simos
Last name: Gerasimou

Re: Automated migration of FileZilla libraries

#3 Post by sim0s » 2017-03-28 14:59

Hi botg,
configure is a generated file, I suppose the error is either in configure.ac or one of the .m4 files.
I assume this is the problem too.

Is there any way to identify what is the problem? e.g., from your experience when you carried out the transformation from TinyXML to PugiXML, did you make any changes to Makefiles and config files other than:
- configure.ac
- src/Makefile.am
- src/interface/Makefile.am
- src/pugixml/Makefile.am
- fz_check_pugixml.m4

User avatar
botg
Site Admin
Posts: 33428
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: Automated migration of FileZilla libraries

#4 Post by botg » 2017-03-28 15:10

I can't remember, it's been so long ago. Try comparing the sources of the different versions to look at the differences, or look at the commits in the repository.

sim0s
504 Command not implemented
Posts: 9
Joined: 2017-01-27 14:42
First name: Simos
Last name: Gerasimou

Re: Automated migration of FileZilla libraries

#5 Post by sim0s » 2017-03-28 15:22

Thanks. I've already done that but couldn't spot any differences. Surely, I am missing something.

Is there any way to do step-wise project compilation so that to track which Makefile/configuration file causes the problem?

User avatar
botg
Site Admin
Posts: 33428
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: Automated migration of FileZilla libraries

#6 Post by botg » 2017-03-28 16:58

Sadly not possible.
Can you configure the original, unmodified 3.11?

sim0s
504 Command not implemented
Posts: 9
Joined: 2017-01-27 14:42
First name: Simos
Last name: Gerasimou

Re: Automated migration of FileZilla libraries

#7 Post by sim0s » 2017-03-29 18:09

botg,

There was a problem with fz_check_tinyxmlnew.m4. I fixed it now. Thanks.

I managed to run the transformation and produced a compilable FileZilla 3.11 that uses TinyXMLNew instead of TinyXML :)

The next steps are to complete the implementation and run some tests.

Q: Most (if not all) files using the XML parser are interface-related, right?

User avatar
botg
Site Admin
Posts: 33428
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: Automated migration of FileZilla libraries

#8 Post by botg » 2017-03-29 18:17

Yes.

sim0s
504 Command not implemented
Posts: 9
Joined: 2017-01-27 14:42
First name: Simos
Last name: Gerasimou

Re: Automated migration of FileZilla libraries

#9 Post by sim0s » 2017-03-30 09:50

Thanks botg.

In your post about migrating from TinyXML to PugiXML, you mentioned that there were ~2000 compilation errors
From here the way forward was clear: Migrate to pugixml. While tedious, changing FileZilla to use pugixml was a simple task. After fixing about two thousand compile errors, almost everything worked directly.
Could you please give some information about these errors? Were the errors caused only due to the migration or did you also redesigned (some part of) FileZilla?

Thanks,
Simos

User avatar
botg
Site Admin
Posts: 33428
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: Automated migration of FileZilla libraries

#10 Post by botg » 2017-03-30 13:19

It's a different API after all, so this kind of compile errors are expected. I probably did some light refactoring while adapting to the new API. The commits related to this should tell the full story.

Post Reply