Conan-center-index: [package] <libtool>/<2.4.6>: libtool package contains hardcoded strings.

[fulara]

libtool package needs hacky rewrite as well - similar as autoconf does thing

I've checked and this time i am 99% sure that issue is not with the steps I am doing.
When using a libtoolize across different directory structure when using it in certain scenario you will be met with this error:

libtoolize:   error: $pkgauxdir is not a directory: 

Problem:
libtoolize has hardcoded string from build time.
this can be seen by checking the package on conan-center, snippet:

prefix=/tmp/c3ipr/pr_659_8_0_0/.conan/data/libtool/2.4.6/_/_/package/7c3162c969f9b7ff318890e3afa2eec7ee343945  
datadir="/tmp/c3ipr/pr_659_8_0_0/.conan/data/libtool/2.4.6/_/_/package/7c3162c969f9b7ff318890e3afa2eec7ee343945/bin/share" 
pkgauxdir="/tmp/c3ipr/pr_659_8_0_0/.conan/data/libtool/2.4.6/_/_/package/7c3162c969f9b7ff318890e3afa2eec7ee343945/bin/share/libtool/build-aux"
...

in file: libtoolize line ~4290

from package: bintray-link

Proposed solutoin:
This is bash script so probably can just use environmentals set by package_info().

Thoughts @madebr - sorry to be tagging you like this - but you are an expert onthis! :)?
If you agree to my proposal I can probably make changes.

[madebr]

@fulara Can you recheck using #1102?

Thoughts @madebr - sorry to be tagging you like this - but you are an expert onthis! :)?
If you agree to my proposal I can probably make changes.

No problem mate. It's good to have an extra set of eyes looking at these packages as they might be used by a lot of people.

[fulara]

Oh. sorry for spamming with issues then, I should have done the search first - It did not even click that this could be raised and waiting.
Lucky me actually!

I'll download and test, but the changes look good.

[fulara]

Hello @madebr it seems your new recipes does not work for me..
I am still investigating however it seems that your recipe forces the path to be lowercase?
prints:

libtool/2.4.6: Setting LIBTOOLIZE env to /var/build/bamboo/agent-home/xml-data/build-dir/cir-neovim0-job1/.conan-standalone/bamboo/.conan/data/libtool/2.4.6/_/_/package/2d455a25ea25b58c83e8696a7385f7159b7451e7/bin/libtoolize

but the real directory is...

ls /var/build/bamboo/agent-home/xml-data/build-dir/CIR-NEOVIM0-JOB1/.conan-standalone/bamboo/.conan/data/libtool/2.4.6/_/_/package/2d455a25ea25b58c83e8
696a7385f7159b7451e7/bin/libtoolize

note:
CIR-NEOVIM0-JOB1
vs cir-neovim0-job1.

I am looking at your recipe where it happens.
btw these caps dirs is something that bamboo steers.

[fulara]

This seems to be a bug with unix_path.
I am still checking.
confirmed:

   code:  raise Exception(tools.unix_path("HAI"))
results in: Exception: hai

Forces lowercase path on unix. definitely undesired behavior.

I am changing recipe locally to remove the use of unix_path.

[fulara]

another thing.
got an error while building other package (subversion):

Libtool helper path not found (try setting the LIBTOOL_M4 environment variable)
24-Apr-2020 01:28:37 | expected at: '/var/build/bamboo/agent-home/xml-data/build-dir/CIR-SUBVERSION0-CONRH7/.conan-standalone/bamboo/.conan/data/libtool/2.4.6/_/_/package/2d455a25ea25b58c83e8696a7385f7159b7451e7/bin/../share/aclocal'

weird, there is no mention of the LIBTOOL_M4 variable as i see it.

Okay - thats because your libtool build puts 'share' into bin, thats a bit weird btw..

[madebr]

weird, there is no mention of the LIBTOOL_M4 variable as i see it.

LIBTOOL_M4 seems to be a configuration environment variable of subversion's autogen.sh, as you've already detected.

Okay - thats because your libtool build puts 'share' into bin, thats a bit weird btw..

I completely agree.

@uilianries
Why is this actually?
It is weird that we have to move the share folder to a non-standard location because the hooks don't accept any other root folders then bin, lib and licenses.
This move can introduce subtle bugs.

[fulara]

the share being moved into bin is a common thing for multiple autotools conan packages here.
so two things from me:
1) forced lowercase breaks my build completely, cant use that at all.
2) because of abnormal directory structure some packages willnot work - like subversion already showed not to work, I had to hack the libtoolize and export these variables, this allowed me to go further.. but I still am not complete with my journey as i am dealing with apr -_-

[madebr]

@fulara
I found some more paths in libtool, that caused problems on msys2 on Windows.
See #807

[fulara]

@madebr nice.
In the end when doing the apr-utils locally I just decided to sed -i [email protected]_folder@CONAN_PLACEHOLDER@ and just do it like that as I got super tired of these paths :) so kudos to you for having patience about this.

I checked your build - it builds for me, and I dont see hardcoded paths ( check done by invoking grep -r 'package_hash' )

I had patience while doing apr and I plan to actually posting the recipe here once I get some more testing ground.

I am still unsure about these though.
1) unix_path breaks it completely and I am unable to use this on my linux machine. I can raise a pr and change unix_path into somethine like:

def fixed_unix_path(self, p):
   if self.settings.os = "Linux": 
        return p
   return tools.unix_path

But since I didnt get any response to that I am not sure if thats a bug, and if thats a bug this can be fixed in next release, if this is not a bug ( and i'd be suprirsed it hat was the case I could commit that int othis PR.
2) What about share sitting in the bin dir?

Both 1) and 2) are breaking for me and I have to maintain a local version of the recipe.

[madebr]

@fulara
Please check #1460 and #1462

unix_path breaks it completely

I'll add a patch to #807 conditionally calling tools.unix_path when on Windows.

What about share sitting in the bin dir

That is a limitation set by this repo / hoods / @uilianries .
What problems is it causing you?

[fulara]

w00t, apr and apr-util.
man you are too good.

I got my build of svn finally working, with my uber hacky recipes.
short headsup what I am doing:
I wanted to have git with git-svn support enabled to went to building svn which turned out to be huge pain.
And I have to support rh6 and rh7 and they basically dont have anything!

I found here pcre (on conan center ) and swig (in the net) and they actually saved my bottom. but I had to hack the swig recipe slightly.

I think tonight I will find a time to spend a little time on it - I wanted to move on since svn finally built but I'll test your recipes of apr and apr-util.

swig is actually called swig_installer - convention is super weird to me but it seems that has been now deprecated ( as cmake shows )

[uilianries]

I can't remember why it's forced to lower case, the last change was 2 year ago ... but for unix systems it doesn't make any sense. unix_path is under windows tools, so we could check before using it, or, skip it when calling under unix system.

[fulara]

@uilianries what about this:

What about share sitting in the bin dir

That is a limitation set by this repo / hoods / @uilianries .

share directory should be on the same level as the bin directory.
I think we should rework that.

[madebr]

@uilianries what about this:

What about share sitting in the bin dir

That is a limitation set by this repo / hoods / @uilianries .

share directory should be on the same level as the bin directory.
I think we should rework that.

@uilianries @danimtb
Can you please give your opinions on the matter of a share folder in the root package folder?

[Croydon]

I found here pcre (on conan center ) and swig (in the net) and they actually saved my bottom. but I had to hack the swig recipe slightly.

I think tonight I will find a time to spend a little time on it - I wanted to move on since svn finally built but I'll test your recipes of apr and apr-util.

swig is actually called swig_installer - convention is super weird to me but it seems that has been now deprecated ( as cmake shows )

The Bincrafters community and the community here has a strong overlap.

_installer suffixes is an old convention indeed. We won't add it for new recipes anymore.

swig_installer can be migrated to to CCI after #1473 is merged and then it will be called just swig

[uilianries]

Can you please give your opinions on the matter of a share folder in the root package folder?

There is no matter, it's a convention because most of projects install on the root level, that's it. We remove share folder because it's useless for building, usually contains only documentation. But if it's a requirement for this project, I see no problem adding it.

[madebr]

@fulara Can you please explain why the share folder is needed for your use case?

[fulara]

@madebr @uilianries sure.
When building subversion it failed with an error:

Libtool helper path not found (try setting the LIBTOOL_M4 environment variable)
24-Apr-2020 01:28:37 | expected at: '/var/build/bamboo/agent-home/xml-data/build-dir/CIR-SUBVERSION0-CONRH7/.conan-standalone/bamboo/.conan/data/libtool/2.4.6/_/_/package/2d455a25ea25b58c83e8696a7385f7159b7451e7/bin/../share/aclocal'

Problem here is not about cc build is not removing the share directory. its moving it into the bin directory. this is the directory structure that your current artifact produces:

bin
bin/share
bin/share/aclocal/
bin/share/aclocal/...
bin/share/libtool/
bin/share/libtool/...
licenses/

This is unorthodox.
I am not an expert here - but usually these tools would have share dir parallel to the bin.
Becuase of the way cci build it structure other tools like, svn above get confused.
Therefore I had to change your recipe to export two additional variables.

        self.env_info.LIBTOOL_M4 = libtool_aclocal
        libtool_config = os.path.join(self.package_folder, "bin", "share", "libtool", "build-aux")
        self.env_info.LIBTOOL_CONFIG = libtool_config

Only after that svn was happy.

Now - you might argue that this is a problem with svn - I wouldnt be so quick about that, because with my original recipe of libtool svn built fine without setting these environmental variables.

On top of that its not really feasible to set this in the subversion recipe because going by the recommended way you guys propose the libtool will not be build_requires of subversion explicitly, I would be setting that in the profile section [build_requires].
So I would have to aproach this in a really hacky way if I didnt want to change libtool recipe.

[madebr]

@fulara
I completely agree with you that moving the share folder is non-standard.

It looks like subversion misses just 2 environment variables.
I think you can make your recipe build with the current libtool pr by surrounding the build commands with:

with tools.environment_append({"LIBTOOL_M4": tools.get_environ("ACLOCAL_PATH"), "LIBTOOL_CONFIG": os.path.join(self.deps_cpp_info["libtool"].rootpath, "bin", "share", "libtool", "build-aux")}):
    autotools = AutotoolsBuildEnvironment(self)
    autotools.configure()
    autotools.make()

But maybe it is interesting to add LIBTOOL_M4 and LIBTOOL_CONFIG to package_info of libtool.
Because they are only of use for certain recipes, I'll probably make them available through user variables instead of environment variables.

[fulara]

@madebr
Is that a good way of doing things tho?
This makes assumption that I will have build_requires against libtool at all times. :)
Adding it to libtool would be ideal actually, thats what I've done.
Alternatively I can just patch the subversion.

[madebr]

@fulara
I'm gonna leave the share folder at the location as it is now.
As I see it it: LIBTOOL_M4 and LIBTOOL_CONFIG are variables that are only used by subversion and are thus to be configured in the subversion recipe.

I see that I'm already setting the LIBTOOL_PKGAUXDIR and LIBTOOL_ACLOCALDIR environment variables in package_info but are not public.
I've just changed that such that recipes like subversion can use this information.

You can just forward these variables to the appropriate subversion configuration variable.

[fulara]

@madebr cool. I understand.
I saw your changes around unix_path, look good to me.
I have no further problem with the recipe.

[fulara]

this issue was closed by already merged (14.. ) and my further comments are in #807 closing.