Well, you can build just the library by issuing make src/libmpg123/libmpg123.la, but there's no separate install target just for this. Well, there probably is some automake-internal target.
Do you need full make install support for "just the lib"? And do you only mean libmpg123?
--
sent from mobile device, trustworthy or not
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After make src/libmpg123/libmpg123.la, you got the result in src/libmpg123/.libs, FWIW. Ypu can take the .so or .a file and have fun with it. But I see that you'd like to install only the selected parts into a target prefix.
We could add something for that. But a step back: Do you have actual trouble building the app and other libs? Where from does the need arise? The whole thing is not exactly heavy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have no trouble, it's just that made an installer on Windows for dependencies of a framework, and I only need the library. So I have to remove by hand in my scripts the binaries (i need headers, not only the lib). Not a big deal, though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
--disable-components doesn't seem to disable modules, which I believe that it should.
Modules are a part of libout123 if it is built. I thought that's
optional. What do you expect, exactly? Hm. You mean you'd also like to
be able to build exactly one output module, without the libs?
Separating package builds for binaries, libraries, modules?
Well, I don't need the output modules at all: they make sense only when libout123 is built, do they not?
As for my specific use case: In one of my windows (mingw) build attempts, the configury looked for GetThreadErrorMode (because modules weren't disabled as I had first thought) and errored out when it failed to find it in my old outdated toolchain. When I added --disable-modules after --disable-components, things worked just fine.
Not really a big thing, but for me --disable-components implies --disable-modules, but it's just me..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wait, you had a configure failure with --disable-components just because modules weren't disabled? The tests for them should just fail and disable modules, not break your build.
I'll have to think a bit about that before release. I see how you can see the modules as separat component at the same level as the libs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only args to configure were --disable-components --host=x86_64-w64-mingw32
checking if we have GetThreadErrorMode... checking if we have GetThreadErrorMode... no
configure: error: GetThreadErrorMode is required but not found
Thanks. This has nothing to do with --disable-components, though. If
modules are not disabled per choice, you get that error if
GetTheadErrorMode is not available in a Windows context.
We should change that to simply disable modules (in case they're not
enabled explicitly by the user) instead of fail.
I also thought a bit: the modules switch really is not just about
building modules themselves, but about building libout123 with the
feature of being able to load modules. You can choose a list of modules
to build, anyway (need to mentally separate the concepts of
--with-audio and --with-default-audio).
What I will test is how a a build of --disable-components
--enable-modules --with-audio=... works to build only audio modules.
Distros hack around that a bit right now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, you can build just the library by issuing make src/libmpg123/libmpg123.la, but there's no separate install target just for this. Well, there probably is some automake-internal target.
Do you need full make install support for "just the lib"? And do you only mean libmpg123?
--
sent from mobile device, trustworthy or not
i'll see if make src/libmpg123/libmpg123.la is sufficient for me. If so, i'll let you inform
thank you
Vincent Torri
make src/libmpg123/libmpg123.la install
still build the exeOf course, the install target depends on the whole thing. This is what I meant.
After make src/libmpg123/libmpg123.la, you got the result in src/libmpg123/.libs, FWIW. Ypu can take the .so or .a file and have fun with it. But I see that you'd like to install only the selected parts into a target prefix.
We could add something for that. But a step back: Do you have actual trouble building the app and other libs? Where from does the need arise? The whole thing is not exactly heavy.
I have no trouble, it's just that made an installer on Windows for dependencies of a framework, and I only need the library. So I have to remove by hand in my scripts the binaries (i need headers, not only the lib). Not a big deal, though.
I added now
./configure --disable-components --enable-libmpg123
which only builds libmpg123, also for the install target. Does that do the trick?--disable-components
doesn't seem to disablemodules
, which I believe that it should.Am Thu, 07 Sep 2023 04:35:36 -0000
schrieb "Ozkan Sezer" sezero@users.sourceforge.net:
Modules are a part of libout123 if it is built. I thought that's
optional. What do you expect, exactly? Hm. You mean you'd also like to
be able to build exactly one output module, without the libs?
Separating package builds for binaries, libraries, modules?
Otherwise, please specify the use case.
Well, I don't need the output modules at all: they make sense only when libout123 is built, do they not?
As for my specific use case: In one of my windows (mingw) build attempts, the configury looked for GetThreadErrorMode (because modules weren't disabled as I had first thought) and errored out when it failed to find it in my old outdated toolchain. When I added
--disable-modules
after--disable-components
, things worked just fine.Not really a big thing, but for me
--disable-components
implies--disable-modules
, but it's just me..Wait, you had a configure failure with
--disable-components
just because modules weren't disabled? The tests for them should just fail and disable modules, not break your build.I'll have to think a bit about that before release. I see how you can see the modules as separat component at the same level as the libs.
Thank you.
Please confirm the kind of breakage you have seen. What was the exact configure line? I'd like to see the break in the logic before changing it again.
The only args to configure were
--disable-components --host=x86_64-w64-mingw32
The full output below, using latest unmodified svn:
Am Wed, 13 Sep 2023 10:22:28 -0000
schrieb "Ozkan Sezer" sezero@users.sourceforge.net:
Thanks. This has nothing to do with --disable-components, though. If
modules are not disabled per choice, you get that error if
GetTheadErrorMode is not available in a Windows context.
We should change that to simply disable modules (in case they're not
enabled explicitly by the user) instead of fail.
I also thought a bit: the modules switch really is not just about
building modules themselves, but about building libout123 with the
feature of being able to load modules. You can choose a list of modules
to build, anyway (need to mentally separate the concepts of
--with-audio and --with-default-audio).
What I will test is how a a build of --disable-components
--enable-modules --with-audio=... works to build only audio modules.
Distros hack around that a bit right now.
There's
--enable-libout123-modules
now.