build: make it possible to disable the build of the flex program

[tpetazzoni]

The flex program uses fork(), which isn't available on noMMU
systems. However, the libfl library does not use fork(), and be used
by other programs/libraries.

Therefore, it makes sense to provide an option to disable the build of
the flex program.

Signed-off-by: Thomas Petazzoni thomas.petazzoni@free-electrons.com

[Explorer09]

I'm considering that building libfl alone should be the corner case, and I don't think having a config option for disabling that benefit much (comparing to the additional Makefile code).
And this doesn't stop configure from checking fork() anyway.

Is there any problem if you run configure like normal, and then do make -C src libfl.a to make only the library?

And by the way, the code in libfl is soooo trivial - you might consider not linking with libfl at all in your code.

[tpetazzoni]

Buildroot is a embedded Linux build system, which packages a lot of different upstream components. Therefore, we do not decide to link with libfl or not: it's the decision of various upstream components. Currently in Buildroot, we have quite a few packages in this situation: at, checkpolicy, gnuchess, ipsec-tools, libcue, linux-pam, radvd.

Would you accept a patch that instead of adding a configuration option, detects if fork() is available, and disable the building of the flex program in this case ?

Thanks!

[westes]

I'm actually ok with having an option to disable the building of flex. It seems the most straight forward way to get the case you're after. It's not strictly necessary but it could add uniformity and it won't bother most people.

…

On Saturday, 26 August 2017, 7:02 pm +0000, Thomas Petazzoni ***@***.***> wrote: Buildroot is a embedded Linux build system, which packages a lot of different upstream components. Therefore, we do not decide to link with libfl or not: it's the decision of various upstream components. Currently in Buildroot, we have quite a few packages in this situation: at, checkpolicy, gnuchess, ipsec-tools, libcue, linux-pam, radvd. Would you accept a patch that instead of adding a configuration option, detects if fork() is available, and disable the building of the flex program in this case ? Thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #256 (comment)

-- Will Estes westes575@gmail.com

[tpetazzoni]

OK. Let me know if I need to change my patch, or if it is good as it is. Thanks!

[Explorer09]

But what about the testsuite? You probably need to disable the testsuite as well when flex is not built.

@tpetazzoni Can you describe the problem in detail? I still don't understand what really happened in Buildroot. Are there really upstream packages that link with -lfl? And then what's exactly the case that you need to build libfl alone?

I'm considering that dependency to libfl is the worst idea for package's portability. IIRC, libfl is only there for POSIX compatibility 1 and any package should provide replacements instead of depending on it. (%option noyywrap or even a simple -D'yywrap()=((int)1)' would work in place of -lfl most of the time.)

[westes]

No, "make all" would not build the test suite.

…

On Sunday, 27 August 2017, 1:23 am +0000, "Kang-Che Sung (宋岡哲)" ***@***.***> wrote: But what about the testsuite? You probably need to disable the testsuite as well when flex is not built. @tpetazzoni Can you describe the problem in detail? I still don't understand what really happened in Buildroot. Are there really upstream packages that link with `-lfl`? And then what's exactly the case that you need to build libfl alone? I'm considering that dependency to libfl is the worst idea for package's portability. IIRC, libfl is only there for POSIX compatibility [1](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/lex.html) and any package should provide replacements instead of depending on it. (`%option noyywrap` or even a simple ` -D'yywrap()=((int)1)' ` would work in place of `-lfl` most of the time.) -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #256 (comment)

-- Will Estes westes575@gmail.com

[Explorer09]

@westes What I'm saying is that make check would fail. And if there are automated build systems that do run make check before make install, you know what would happen.

[westes]

Yes, but if someone passes the flag to disable the build of flex itself and doesn't also skip the test suite, that's their problem, not mine.

…

On Saturday, 26 August 2017, 6:36 pm -0700, "Kang-Che Sung (宋岡哲)" ***@***.***> wrote: @westes What I'm saying is that `make check` would fail. And if there are automated build systems that do run `make check` before `make install`, you know what would happen. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #256 (comment)

-- Will Estes westes575@gmail.com

[Explorer09]

I'm still not convinced. I would personally add a make libfl target in the top level makefile rather than complicating the configure script like that. (And probably also make install-libfl -- it's trivial to implement both in Makefile.)
fork() should not be the only reason for not building flex anyway, because ideally we should be able to make flex work with vfork(). And vfork is available in a no-MMU system, isn't it?

[tpetazzoni]

@Explorer09 Well, I think I already explained the problem in detail: the flex program needs fork(), which means it cannot build on no-MMU systems. However, the libfl library, which is used by a number of other software packages (see the list I provided) does not require fork(). Therefore, it is clearly useful for flex to support the ability to build just its library and not its flex program.

We have been having a hack for this in Buildroot since many, many years. I'm now trying to solve thisi properly, in a form that can be accepted upstream (i.e by you). But well, if you really don't understand our use case, I guess we'll just keep our patch locally and that's it.... but that would really be a shame, as we're trying hard to avoid having patches, by making lots of efforts to submit them to the respective upstream projects.

Also, I really don't see where is the additional complexity in the patch I'm proposing. It's a trivial new configure.ac option, with the default being to keep the existing behavior. I.e, there is no change for anyone, except an improvement for those who are interested in building just the library.

And no, special calling "make libfl" and "make install-libfl" is not really nice. Indeed, the whole point of autoconf/automake is that you have a well-defined ./configure && make && make install procedure. Having to deviate from that is not really nice to maintain.

[westes]

To be clear, I am the maintainer of flex and therefore the decision maker. I actually like @Explorer09's suggestion of additional Makefile targets. Other people could find those useful in addition to systems where fork() is not available. To recap: He suggested targets of "libfl" at the top level and "install-libfl" at the top level. which would only build libfl and install libfl respectively. Would that fit in your build system?

…

On Sunday, 27 August 2017, 8:56 am +0000, Thomas Petazzoni ***@***.***> wrote: @Explorer09 Well, I think I already explained the problem in detail: the flex program needs fork(), which means it cannot build on no-MMU systems. However, the libfl library, which is used by a number of other software packages (see the list I provided) does not require fork(). Therefore, it is clearly useful for flex to support the ability to build just its library and not its flex program. We have been having a hack for this in Buildroot since many, many years. I'm now trying to solve thisi properly, in a form that can be accepted upstream (i.e by you). But well, if you really don't understand our use case, I guess we'll just keep our patch locally and that's it.... but that would really be a shame, as we're trying hard to avoid having patches, by making lots of efforts to submit them to the respective upstream projects. Also, I really don't see where is the additional complexity in the patch I'm proposing. It's a trivial new configure.ac option, with the default being to keep the existing behavior. I.e, there is no change for anyone, except an improvement for those who are interested in building just the library. And no, special calling "make libfl" and "make install-libfl" is not really nice. Indeed, the whole point of autoconf/automake is that you have a well-defined ./configure && make && make install procedure. Having to deviate from that is not really nice to maintain. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #256 (comment)

-- Will Estes westes575@gmail.com

[Explorer09]

My opinion is that an option for disabling the main program in configure, which, if disabled, would break make check and make doc or turn them to no-ops, is not nice. When I mentioned about the make check breakage in previous post, westes hinted to me that it's "their problem" and we don't need to care. Since it's the same effort for package builders to specify one more configure option as to make only the libfl target, I really don't like the bloat to configure script of one more conditional.

There's no practice of having an option to disable main program in any other package, at least not in gcc or bison. In gcc, if you wish to build only the libstdc++ library, you either run configure script of the libstdc++-v3 subdirectory, or configure the top directory and then run make all-target-libstdc++-v3 -- you can consider both ways are "hacks".

In short, you gotta need some "hacks" anyway when you intend only to build the library. My proposal was to make you convenient to do that, and I think a makefile target is enough for this case. Having a "smooth" make && make install procedure in secondary, IMHO.

[westes]

Yes, I like the separate Makefile targets better. It is cleaner and would benefit more people than just the non-MMU case. @Explorer09, could you submit a pull request for it?

…

On Sunday, 27 August 2017, 9:04 am -0700, "Kang-Che Sung (宋岡哲)" ***@***.***> wrote: My opinion is that an option for disabling the main program in `configure`, which, if disabled, would break `make check` and `make doc` or turn them to no-ops, is not nice. When I mentioned about the `make check` breakage in previous post, westes hinted to me that it's "their problem" and we don't need to care. Since it's the same effort for package builders to specify one more configure option as to make only the libfl target, I really don't like the bloat to configure script of one more conditional. There's no practice of having an option to disable main program in any other package, at least not in gcc or bison. In gcc, if you wish to build only the libstdc++ library, you either run configure script of the `libstdc++-v3` subdirectory, or configure the top directory and then run `make all-target-libstdc++-v3` -- you can consider both ways are "hacks". In short, you gotta need some "hacks" anyway when you intend only to build the library. My proposal was to make you convenient to do that, and I think a makefile target is enough for this case. Having a "smooth" `make && make install` procedure in secondary, IMHO. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #256 (comment)

-- Will Estes westes575@gmail.com

[westes]

We're not going to do this but instead will add Makefile targets to enable building of libfl as in #258. At time of writing, there are some issues to be fixed with that request, but that or something very much like it will be in 2.6.5.