can you rename one of lzma.h

2014-04-26
2014-09-13
  • Gilles Vollant

    Gilles Vollant - 2014-04-26

    I suggest you rename src\liblzma\api\lzma\lzma.h to don't have two file with same name.

    when I setup a new project, I often spend time to check conflict between these two file

     
  • Gilles Vollant

    Gilles Vollant - 2014-04-29

    Under MacOSX, I've also sometime conflict with Block.h from OSX toolkit

     
  • Lasse Collin

    Lasse Collin - 2014-05-04

    I renamed lzma/lzma.h to lzma/lzma12.h in the git repository. I'm not sure what kind of technical problem it caused but I renamed it because this way it's less confusing to humans. :-)

    Can you explain how lzma/block.h can be a problem? It shouldn't be in the preprocessor search path since it's a private header and thus the preprocessor shouldn't be able to find it unless one specifies it with the subdir <lzma/block.h>.

     
  • Gilles Vollant

    Gilles Vollant - 2014-05-04

    macosx header contain also a block.h, and compiler made confusion between both file (from apple and from xz util)

    there is also two check.h

     
  • Lasse Collin

    Lasse Collin - 2014-05-04

    I understood that but I don't understand why it happens. The directory containing block.h and check.h in liblzma shouldn't be in the preprocessor search path even when compiling liblzma itself. Thus those files shouldn't be found accidentally; one needs to use "lzma/block.h" or full path to refer to them.

    I think this problem shouldn't occur with the Autotools based build system included in XZ Utils, so I assume you are using something else. Please check that you haven't accidentally added the directory of the private headers to the search path.

     
  • Gilles Vollant

    Gilles Vollant - 2014-07-27

    The xcode header management is very special, and having a conflict with name of system header and application header is a headache.

    So if you can rename block.h (and rename at least one of your two different check.h), this will just save me from nightmare!

     
  • Lasse Collin

    Lasse Collin - 2014-09-13

    src/liblzma/api/lzma should never be in the search path. If Xcode really is so broken that one cannot avoid getting that in the search path, Xcode should be fixed. I admit that XZ Utils include paths could be simpler, but for any sane build system they shouldn't cause any significant trouble.

    With a quick search I found that other people have had similar problems with other projects. One suggested solution was to uncheck "Recursive" from "Header Search Path". Another was to set USE_HEADERMAP=NO.

    I hope you get it solved. If you do, I could like to add the information to the INSTALL file so other people won't have a problem with it. If you cannot find an easy fix, let me know but please complain to Apple too. :-)

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks