From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Building with 'make install T=' and 'make config T='
Date: Wed, 09 Dec 2015 17:19:09 +0100 [thread overview]
Message-ID: <3389553.DHxrbPlyKc@xps13> (raw)
In-Reply-To: <D2F4367E-AA91-4CBD-AD9C-92801E79F8CD@intel.com>
2015-12-09 15:32, Wiles, Keith:
> On 12/9/15, 8:59 AM, "Thomas Monjalon" <thomas.monjalon@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 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.
> >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.
> 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.
next prev parent reply other threads:[~2015-12-09 16:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-09 14:39 Wiles, Keith
2015-12-09 14:59 ` Thomas Monjalon
2015-12-09 15:32 ` Wiles, Keith
2015-12-09 16:19 ` Thomas Monjalon [this message]
2015-12-09 17:31 ` Wiles, Keith
2015-12-09 17:44 ` Wiles, Keith
2015-12-09 17:52 ` Thomas Monjalon
2015-12-13 2:03 ` [dpdk-dev] [PATCH] scripts: add help for build testing Thomas Monjalon
2015-12-14 22:04 ` Thomas Monjalon
2015-12-09 17:56 ` [dpdk-dev] Building with 'make install T=' and 'make config T=' Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3389553.DHxrbPlyKc@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).