On 12/9/15, 11:31 AM, "dev on behalf of Wiles, Keith" <dev-bounces at dpdk.org on behalf of keith.wiles at intel.com> wrote:
>On 12/9/15, 10:19 AM, "Thomas Monjalon" <thomas.monjalon at 6wind.com> wrote: BTW, I am not overly concerned about the build system per say I just wish I had put my $0.02 worth in before the change. We can leave as it is now. The test-build.sh script build does appear to be a real problem. I would like to understand why it does not work. Adding a better help message should be an easy fix for someone that wrote the script or I can make the changes, just let me know. > >>2015-12-09 15:32, Wiles, Keith: >>> On 12/9/15, 8:59 AM, "Thomas Monjalon" <thomas.monjalon at 6wind.com> wrote: >>> >>> >2015-12-09 14:39, Wiles, Keith: >>> >> I am having a problem with ?make install T=? command as I was using it >>> >> before. I would normally build a x86_64-native-linuxapp-gcc, clang and >>> >> icc or a different config all together. Currently the ?make install T=? >>> >> gives a warning message at the end of the build plus creates the >>> >> x86_64-native-linuxapp-XXX directory. If I use the suggested ?make >>> >> config T=? command this command create a directory ?build? with a >>> >> .config file. The problem is this method does not allow me to have >>> >> multiple builds at the same time. >>> >> >>> >> What is the suggested method to have multiple builds without installing >>> >> into the local file system? >>> > >>> >The multiple build is not supported anymore. It was only building with >>> >the default configuration. >>> >If you want to test various builds, I suggest to use this script: >>> > scripts/test-build.sh >>> > http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c >>> >>> Having a build script is great, but it give me an error on building. The >>> script does not have a ?help option and the unknown option is not very >>> usefulas it does not explain the two option -jX and -s in that output >>> message. I would have expected a bit more help instructions on using this >>> command and adding a -h or ?help would be useful. >> >>Please check. >>There is a -h option. > >The -h option gives the same output as the a unknown option: > >rkwiles at rkwiles-supermicro (master):~/.../intel/dpdk$ >./scripts/test-build.sh -h >usage: test-build.sh [-jX] [-s] [config1 [config2] ...]] >rkwiles at rkwiles-supermicro (master):~/.../intel/dpdk$ > > >My point was more around the content of the help as it is not very useful as >to what the -jX or -s options are, please add more help information as ?man >test-build.sh? does not work :-) > >> >>> The error I get from the following command is: './scripts/test-build.sh >>> x86_64-native-linuxapp-gcc? building on a Ubuntu 15.10 with all patches. If >>> I use ?make install T=x86_64-native-linuxapp-gcc? this command builds >>> correctly with the warning at the end. >>[...] >>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c: >>> In function \u2018pci_config_extended_tag\u2019: >>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:505:2: >>> error: ignoring return value of \u2018fgets\u2019, declared with attribute >>> warn_unused_result [-Werror=unused-result] >>> fgets(buf, sizeof(buf), f); >>> ^ >> >>It is a compilation error, not related to the script. > >This is strange the ?make install T=? command just works, how do you explain >that problem. >The test-build.sh script should be do some setup then ?make config T= ; make? >so why is this script not working? > >The script should work as expected with ?./scripts/test-build.sh >x86_64-native-linuxapp-gcc? correct? > >Could be something wrong with my system, but I doubt it. > >> >>> >If you just want to compile, it is simple: >>> > make config T=x86_64-native-linuxapp-gcc O=my-gcc-build >>> > make O=my-gcc-build >>> >>> IMO we have gone backwards in making DPDK easy to build. I agree using >>> ?make install T=? may not be the best solution as ?install? implies we are >>> installing the code. I agree not we should not try to build multiple >>> configuration with one command, but we should be able to do ?make build >>> T=x86_64-native-linuxapp-gcc? to replace the ?make install T=? command. Now >>> the developer only needs to type one command with to build a configuration >>> and not two. If the developer includes the ?O=? option then the command >>> should create that directory and build the configuration into that >>> directory. For the 80% rule the ?O=? option should not be required. >> >>The O= option is not required. >>The new syntax is closer to the standard behaviour. >>You just don't want to type "make config" because you are using a default >>configuration. > >I understand the O= option is not required. I would have liked it to pick the >closest configuration to the host system if x86-64 then pick >x86_64-native-linuxapp-gcc GCC is the normal default compiler, if a ARM-v7 >system then pick the correct configuration or powerpc ? >If they want something else then let them use the ?T=? option. This would have >been a nice to have feature, but not a requirement. > >> >>> The ?make config T= O=? then ?make O=? series of commands are not required, >>> even the ?config? keyword is not required and just an extra step we do not >>> need. What does the ?config? target really add to the made other then >>> creating the ?build? directory and a config file. I believe the ?build? >>> directory should be dropped/removed all together and just require the ?T=? >>> and/or the ?O=? if they really want to define a different output directory. >> >>Between "make config" and "make" you can modify the configuration. >>In the next release, "make config" will be wrapped by a "configure" script >>which will allow to configure your target in one line. >>So we will end up with: >> ./configure >> make >> make install >>It may be weird to you but it is standard to others. > >I understand the above configure steps and yes it is nice to have, the only >problem is we do not have a real automake-autolib configuration system. > >Personally I would not use automake-autolib as it requires more system >resources and different version cause different problems plus M4 maybe a great >language, but not very friendly. The current DPDK build system just requires >make and a shell, which is very common plus very simple to install. If >cross-compiling it will be harder to get all of the tools in place to support >a real automake system on a embedded environment. Cross-compiling has its own >problems to address. > >I would like to have the above configure style support, but making the build >system a bit more complex is not the answer IMO. > >We should never try to build multiple configurations at the same time without >using some type of script as the test-build.sh. > >Being able to have a very simple build is great and the above steps are great >if you have a configure script/build system. > >I would like to see done: > - The ?build? directory is nothing special and we should not use ?build' as a > default directory name, but use the configuration name i.e. > x86_64-native-linuxapp-gcc or the ?O=? option. Not using ?build? this will > simplify the places objects are created using a common scheme, we require a > configuration name for the build directory always. > - If we do not attempt to build a default host based configuration then we > must require the ?T=? option in the below commands I assume a we do not have > default. > > $ make config T=? [O=?] # Just creates the build directory and > .config file as it does today. (Possible default build configuration) > $ make [build] T=? [O=?] # optional ?T=? option but that would > require the build to build all configuration directories which is not desired. > # Just a 'make? assume ?make build? > $ make install [T=?] [O=?] # installs a possible default or uses the > T= configuration. If the configuration directory does not exist then if does > a build first. > >Using the following we can still have the ./configure above. > $ ./configure > $ make [build] > $ make install # or just make install without the ?make?/?make > build' > >Sorry, I missed the original emails as I was very busy and then on vacation. > >> > > >Regards, >Keith > > > > > Regards, Keith
